I was considering Sequelize as nodejs orm, but ran into issue while modifying the schema it does not support new columns directly. This SO thread states "migrations" framework as workaround. This seems to be a development overhead especially after first cycle of changes you will end up either deleting the test data or will have to create migration for each new column change. does node-orm or bookshelf have the same problem? I am using postgres database.
Using sequelize's migrations, you do not need to create a new migration for each column change as you can include many changes within a migration.
I use fixtures to load my test data so that migrations do not affect my data.
I haven't tried node-orm nor bookshelf, however I have no reason yet to stop using sequelize!
Related
I started an angular/express project some weeks ago. I found knex.js and was using it for seeding/migrations and then I realized I could use it's query builder to perform the CRUD operations as well. I think my last missing piece is an ORM. I'm looking for a widely used library that can generate the DB tables into JavaScript objects so I don't have to do it from scratch / continuously modify as I build, does anyone have any suggestions?
Thanks!
Here are some ORMs, you can use them to create the model classes for application based on the DB tables.
Sequelize
TypeORM
I have a database (PostgreSQL) in development environment, which allows me to develop a GraphQL api in NodeJS. I would like to know how to do when I make modifications to the database, pass these modifications to staging and then to production automatically, without having to redo all the queries and so on in each environment.
Do you know how to do it?
Thank you
A typical solution is to use something like migrations. You should have a special table that stores an information about all applied migrations.
The first migration can just execute an initial script that creates all tables, relations, functions and so on.
The subsequent migrations modify structure according to changes in your app and you always know what migrations was applied to a certain DB.
To achieve working with migration you should find a suitable package that can create, execute and undo migrations and maybe seeders as well (something like this package).
I have a prototype server connected to a PostgreSQL database. Because I'm iterating rapidly, I'm creating tables and changing the schemas all the time. I've looked for an npm package which allows me to create such tables and update existing schemas once the server starts, but the options I've found are tied to an ORM implementation, which I do not need.
TL;DR: Are there any npm packages to automatically create tables and update schemas according to a single configuration object provided to it?
A little late, but node-pg-migrate should do what you need.
I've got a Express web api using sequelize that i want to do end to end testing with. I want to be able to do end to end testing with an in memory database so i can run it on whatever machine pleases me.
I use mysql database for development and production, however i was thinking about using an in-memory sqlite database for testing but i'm not sure what the best way is to get test data into it.
There are several modules around like squelize-fixtures but none of them seem to be able to just fill the database with data without the need to write code around it to manipulate and insert it.
Anyone here doing integration tests with sequelize and sqlite that has figured out a good way of doing it without all the boilerplate code?
If you test this way it won't actually be end-to-end testing since you're using a different database.
However, what is wrong with changing your Sequelize dialect to be sqlite and then using sequelize-fixtures to ingest a file of your data? If you feel this is too onerous you could slog your way through it one time and then just save the sqlite db file for future use. You would then instantiate your Sequelize object with
storage: 'path/to/database.sqlite'
No matter what you do or what storage you choose you're going to have to do some work to seed your database.
I'm working on a node.js server, and using MongoDB with node-mongo-native.
I'm looking for a db migration framework, similar to Rails migrations. Any recommendations?
I'm not aware of a specific native Node.js tool for doing MongoDB migrations .. but you do have the option of using tools written in other languages (for example, Mongoid Rails Migrations).
It's worth noting that the approach to Schema design and data modelling in MongoDB is different from relational databases. In particular, there is no requirement for a collection to have a consistent or predeclared schema so many of the traditional migration actions such as adding and removing columns are not required.
However .. migrations which involve data transformations can still be useful.
If your application is expecting data to be in a certain format (eg. you want to split a "name" field into "first name" and "last name") there are several strategies you could use if the idea of using migration tools written in another programming language isn't appealing:
handle data differences in your application logic, so old and new data formats are both acceptable (perhaps "upgrading" records to match a newer format as they are updated)
write a script to do a once off data migration
contribute MongoDB helpers to node-migrate
I've just finished writing a basic migration framework based on node-mongo-native: https://github.com/afloyd/mongo-migrate. It will allow you to migrate up & down, as well as migrating up/down to a specific revision number. It was initially based on node-migrate, but obviously needed to be changed a bit to make it work.
The revision history is stored in mongodb and not on the file system like node-migrate, allowing collaboration on the same project using a single database. Otherwise each developer running migrations could cause migrations to run more than once against a database.
The migrations themselves are file-based, also helping with collaboration on a single project where each developer is (or is not) not using the same database. So when each dev runs the migration, all migration files not already run against his/her database will be run.
Check out the documentation for more info.