Migrations

[boris-lapouga]

Are there any plans to implement migration functionality?

This seems to be the only thing holding back many teams from shifting to any better ORM concepts like pureORM because migrations are key to big teams and consistency of data changes.

[craigmichaelmartin]

100% agree on the need for managed migrations. The question is whether this library should own that, or have a stricter/smaller scope where a different library in the ecosystem would be used for that (see more below).

To directly answer your question: not at the moment - but only because I'm a one person team, and I didn't set out to create a library. I wish I could say this is my exhaustive effort to create a theoretical masterpiece, and so things like that have been thought through with grand vision. In reality, it has been a "just in time" approach, quickly abstracted out of a codebase, based on the single premise of writing SQL and receiving pure, property structured business objects.

Everything about this library is in service to that idea - yet I'm not even sure the current API is the best (or even an optimal) structure for that idea. What I am sure of, is that I've found this premise (even within the current API) to be extremely productive, and something I couldn't see myself (of my account) going back from.

Chief of my mind is the current "business object" implementation. Despite being "pure" (not db-connected), it houses database info.

I bring this up, because there are at least two paths:

1. Attempt to make this library a full-fledged feature complete package (which would include db migration functionality)
   • In this case, we'd probably want to introduce the concept of "storage objects" which house the database info (table and fields) and which a db migration would key off of - so everything is "in-band".
2. Keep this library as one to be pieced with others in the eco-system. This library is already dependent on a database driver (the only supported one for now is pg-promise), and would likewise be used with other complimentary packages - such as one for one for data migration.
   • In this case, I'd still be open to refactoring the API, but knowing that there are "out-of-band" connections between the business object and sql migrations / database that must be kept in sync separately. This library would "own" the mapping of database driver results to the pure, properly structured business objects based on their expectation; but that is it. It'd have a small and definite scope, being used as one piece of a large puzzle we never see.

Those are two out of lots of other paths. There is no grand plan on my part, other than the guiding principle of writing SQL and receiving pure, property structured business objects. So I am more than open to feedback and thoughts!

If we go with option 2 (or in the meantime even if we go with option 1), here are two db migrations I quickly found that seem like a good fit, but haven't explored in depth https://github.com/rickbergfalk/postgrator and https://github.com/db-migrate/node-db-migrate

[craigmichaelmartin]

Thinking about it for a whopping 3 hours, I'm leaning toward number 2. The premise of this library is to use SQL rather than niche library-specific wrappers to SQL, and supporting managed migrations keyed off javascript objects would add a lot of this niche library-specific params.

The pros of this approach are that this library can be really good at one thing: "owning" the mapping of database driver results to the pure, properly structured business objects based on their expectation. It would exist within a rich ecosystem of complimentary limited-scoped libraries which would work together to accomplish the general goal.

The "con" of this approach is that the business object and sql migrations / database are "out-of-band" (one is not the source of truth of the other) and must be kept in sync separately. However, with an "evolutionary" view of database design there is a natural decoupling between the configured state of the data models and the configured state of the database. I have in mind that the configuration state of the database might naturally be in advance (or behind) of what is actually referenced by the code: whether something is removed from code and then only later removed from the database, or whether something is added to the database but not yet used - this always backward compatible evolution entails allowing the database to be in a different configuration state than the data models configuration.