Pg-promise: Migrations

[leemhenson]

Hi!

What would be your recommended approach to long-term schema mutations alongside the use of pg-promise? A common approach is, of course, the idea of defining migrations which mutate the schema up and down, along with the concept of the _current_ migration state held in a migrations table.

I don't see any explicit support for this sort of thing in pg-promise. Is that because you explicitly prefer an alternative method or is it that you simply haven't felt the need yourself?

[vitaly-t]

What migration? :)

This library doesn't even use any notion of a schema. This is not an ORM, it formats and executes generic queries, that's its whole purpose.

Data migration relates to the database architecture, which is outside of this library's purpose.

[vitaly-t]

@leemhenson there are some packages out there that deal with the data migration, like this one: node-postgres-migrate.

[leemhenson]

Well, I suppose I raise this question because I'm learning about the library in conjunction with looking at vitaly-t/pg-promise-demo.

In that project, you do interact with a schema:

https://github.com/vitaly-t/pg-promise-demo/blob/master/db/sql/products/create.sql

I'm just thinking about the use of this library inside a real-world project, and a natural first step is to think about that sort of stuff.

[vitaly-t]

I understand. And that demo only shows you the best way to organize all your queries and the application structure, if you want to develop a proper product.

Other than that, this framework, as defined, is an advanced promise-based access layer on top of the very basic node-postgres.

There is plenty of documentation to help you understand it better. See it in WiKi.

[leemhenson]

Yep, makes sense.