I tried using https://github.com/building5/sails-db-migrate module for creating migrations but it did not run correctly. Table used to get generated but few columns were missing.
Is there a better way to create and run migrations? Sorry i am new to sails, recently migrated from Php.
So, it turn out i was stupid to think we need a module to write migration in sails. It turn out on sails lift the application automatically creates the table from attributes of the model.
But on trying that i realized the waterline module which takes care of this does not create for foreign-key constraints as of now.They are still working on it.
If you are using a nosql db then you can use the associations
http://sailsjs.org/#!/documentation/concepts/ORM
Time is pass, but nothing changes with sails. Beware use it.
If you already in this trap - try https://www.npmjs.com/package/sails-migrations
So people will get a clean and correct answer: The sails ORM (waterline) already supports auto migration, you can change this in the config file (/config/models.js):
module.exports.models = {
migrate: 'alter'
};
It accepts the following options:
safe - never auto-migrate my database(s). I will do it myself (by hand)
alter - auto-migrate, but attempt to keep my existing data (experimental)
drop - wipe/drop ALL my data and rebuild models every time I lift Sails
http://sailsjs.org/#!/documentation/concepts/ORM/model-settings.html
Related
I've this weird problem. I have a Grails app in which some database changelog files are missing. Therefore, the database has gone out of sync with the domain classes. I've done some changes in the domain classes. When I try to run the database migration plugin, it is creating a diff betweeb the current domain classes and the database and try to execute all the sql commands that has already been run which is causing error in executing the commands that I want to execute.
Is there is a solution for this problem?
If I understand your problem correctly, you can re-create all of the missing changelogs using dbm-generate-changelog. This will create changelogs based on the current data model. Then you can use dbm-changelog-sync to mark those changelogs as EXECUTED (which will populate the DATABASECHANGELOG table). Once the DATABASECHANGELOG table is in sync with the current data model, you can use dbm-gorm-diff to make sure you're not missing any other data model changes.
https://grails-plugins.github.io/grails-database-migration/1.4.0/ref/Maintenance%20Scripts/dbm-changelog-sync.html
NOTE: My answer assumes you're using Grails 2.x and Database Migration plugin 1.4.x, but I believe the process is similar in Grails 3.x with Database Migration Plugin 2.x or 3.x.
I created some tables using rails. Now I want to modify the structure of a few of them. I know it can be done using rails migration. But i was wondering if it would cause any anomaly in the rails app if I modify the schemas using mysql rdbms?
Doing such changes through a migration has the advantage of not losing the changes if you decide to recreate/remigrate the database.
Also it serves as documentation. Imagine if your coworker altered some tables sneakily (and then you both forgot about it).
Technically, updating schemas directly in the database should work, but don't do it.
To add to Sergio's point, you're missing a simple fact - Rails' migrations create the famous db/schema.rb file - from which your migrations pull all their data.
The importance of schema.rb is overlooked - it is one of the most crucial aspects of your application.
db/schema.rb
The schema gives all your migrations a version of your DB to change / add to. Each time you perform a migration, Rails changes the schema file to ensure it has a "blueprint" of your db stored on file.
The schema is then able to rebuild the database using such methods as rake db:schema:load (ONLY RECOMMENDED FOR NEW INSTALLS -- DELETES PREVIOUS DATA)
So whilst there's no problem setting up the db using the db's own native tools, I recommend against it. You need to keep your migrations up to speed so that Rails can build the appropriate tables from its schema.
I'm working on a project using Scala which uses Slick.io for handling database interactions. I have the database schema implemented via Slick using its DDL.
This all works fine when I was starting out but now that I am some way into the project, making changes to the database schema is becoming a pain. I have to drop all the tables, manage data, re-create the schema etc...
I've previously used the PHP framework Laravel which had a nice way of dealing with database migrations & making changes to databases. This was done via a set of classes that were controlled by a timestamp and the "most recent" migrations could be run to make any changes to a database schema.
Does Slick have any equivalent?
Thanks
No, slick itself does not have an equivalent, but you can use something like:
Flyway:
https://github.com/flyway/flyway
http://flywaydb.org/
As you have not given any additional info:
for the play-framework there is an own module, which can be found here: https://github.com/flyway/flyway-play
I am using Entity Framework to handle the database in a server application. The server application is deployed to multiple nodes sitting behind a load balancer. I have now discovered the need to rename some of the tables and some of the table columns in the database. The problem is that I will need to do this without any down-time.
If I was writing my own database layer I could simply check the structure of the database and then run different code depending on if the database structure was upgraded or not and then I could potentially have 0% downtime.
Is it possible to do something like this in entity framework 4 or how do I actually make database changes in production with entity framework? I have searched the web for any solution but to no success. I have also considered having 2 entity framework instances in my app but the amount of code I have to write to switch between them would be far too much and error prone.
So to summarize the question:
Is there any way to rename tables and columns in a database in a production environment using Entity Framework 4 and without any downtime whatsoever?
EDIT
A new idea I got would be to create a view in place of the old table with the old naming scheme referencing the new table. I dont know if this will work. For it to work Entity Framework needs to accept this view like it would be a normal table. Could this be a good idea? Anyone tried anything like this with EF4 ?
Okay! Here is what thought I got -
Create new table in DB than renaming and build EntityFramework solution on that.
You need to deploy this by taking one server off from loadbalancer, update it,point entity framework code to new table structure and then again attach to loadbalancer.
Make the same procedure for all the servers in loadbalancer one by one. Once all are up with updated patch then sync old table and new table and then just delete old table. I am suggesting synching these tables so that you have all the data without data loss might happen in above process.
So in my company we are slowly moving to Rails instead of PHP(Code Igniter to be precise).
So, our actual PHP App is using a Mysql DB and I'd like to connect a new Rails app to this DB but meanwhile our PHP is still running, so I can't change the DB.
I don't really know where I should start to use all the rails features (Or at least as much as possible).
There shouldn't be any harm in connecting your rails app to an existing database. You will need to watch for anything that goes against rails conventions (table names are plurals of models, for example) and either change the database (and your php app) or program around the problem in rails.
But the first step is simply to connect to the database and make models for the existing tables and see what works and what doesn't.
After that, post here with any specific problems.
As a suggestion, take a backup of your database and start out programming against that to build your application and be sure everything works safely.
Well, first of all you should setup the connection in config/database.yml and then start to generate the scaffolding (models, views and controllers) table by table (check the Rails generate command). I am not really sure if you have already generated the app though. Anyway, the generator will also generate a migration script that you obviously dont want to run as the db is already there.
Hope this helps a bit.
Anyway, some resources:
http://guides.rubyonrails.org/
http://railsapps.github.io/
There are two aspects of a Rails app to consider for this scenario:
1: the database connection
Simply put the credentials for this database into database.yml.
A model like "User" will by default attempt to find records and attribute definitions in a table called "users". ActiveRecord will assume there's an auto-incrementing integer primary key on each table. When saving records, it will attempt to write to columns called created_at and updated_at. Those are a few things to be mindful of when making and using the connection.
2: the database migrations
Rails uses migration files to manage a sequence of changes to the database structure. Under normal conditions, someone building a Rails app will be starting with an empty database.
In the case of an existing database, I would recommend making a migration something like:
class BuildLegacyDbStructure < ActiveRecord::Migration
def up
Mysql2.connection.execute_some_sql_file( # made-up function
Rails.root.join('path', 'to', 'file')
)
end
def down
# reverse those changes; bring DB down to blank state
end
end
Another option would be to disable Rails/ActiveRecord's migration-based management of the database entirely. For example Rails will generate a migration when you generate a new model. So if you have an existing users table in your PHP app, and you'd like to make a rails model to use this table, you'd run something like rails generate model User --no-migration.