While reading about the database migration plugin in the book "The Definitive Guide To Grails 2", I came across a question. I understand this plugin is used to migrate an older schema to a newer one that the code base might be expecting to work with. Immediately, the one scenario I could think of why this might be necessary is that a code base expecting to work with a newer schema might try to access properties in domain classes that might not be there (null exceptions). I wanted to know if anyone can help me as to other reasons for migrating the schema so that I can better my thinking on this. Thank you.
The Database Migration Grails plugin is a convenient way to update your database schema. It's not necessarily just to migrate to a completely different schema. The plugin is actually just a wrapper around Liquibase. It aims to integrate the database management into your codebase which makes it easily versioned and tracked with the rest of your code. It also allows for you to easily update your database in a controlled way (dbm-update on start). This works great for continuous deployments.
Related
Perhaps a stupid question, and without code, so I'm not sure I'm on the right StackExchange site. If so, sorry and give me a comment please.
I begin programming in Sinatra (only intranet until now) and in the samples they almost always use migration with activerecord, the same with RoR.
I have experience enough with activerecord itself and it is very helpfull but I'm not sure why migration is always used ? If I create a project I just create a SQL script or a Ruby activerecord script that does the creation of the DB for me and that's it..
If I need the site or script somewhere else I just need to execute that script and ready.
Obviously I'm missing here a lot, so who can me explain the other benefits or point me to a good explanation ?
From Rails docs:
Migrations are a convenient way to alter your database schema over
time in a consistent and easy way. They use a Ruby DSL so that you
don't have to write SQL by hand, allowing your schema and changes to
be database independent.
So, the main two benefits are:
It's like Git for db schema, you won't know how that's useful until you are in a mid-size or big project with many contributors and someone makes a bobo :)
You write ruby code to build your db schema, this way if you decide to move from mysql to pg for example, you don't need to open up pg manual and check code compatibility
Update
In the api docs of migrations, you will find many nice use cases (to be honest i didn't know about half of them) ... check it out (http://api.rubyonrails.org/classes/ActiveRecord/Migration.html)
Building a creation script for your database is great, provided two things:
All your database deployments are on new machines
You get your database schema exactly right the first time
In our modern agile environment we not only don't believe it is possible for a project larger than a few lines of code, we also don't encourage aspiring to it.
Active Record's Migrations offer a way to describe your database incrementally. Each "migration" defines how to add its features to the database ("upgrade"), and how to remove them if necessary ("downgrade").
When running migrations, on top of actually running the scripts, Active Record also maintains its own table (schema_migrations), to remember which migrations have been applied to the database, and which are pending.
This enables you to build your database alongside the features as you develop them. It also facilitates working in teams, since each team member develops her own migrations, and Active Record "stitches" everything together, so you don't have to maintain a monolithic creation script.
I am about to perform database migrations in MVC .NET. I was wondering how can I unit test this.
For example, I would like to apply the migration in this question: Rename a db column. How could I unit test this?
My thoughts:
Migrate all existing migrations, except my latest one which I am going to test
Add data to the context
Apply new migration
Test data still there
If my thoughts makes sense, any idea how to apply these to MVC .NET? Thanks!
For integration test. Just my rough idea. Probably depends on your environment - build server, DB server, deployment making, ...
You have to always have same (known) starting point with database. Either you'll create it manually and commit it into VCS and always manually update to M-1 (M=migration). Or just suppose all the migrations M-1 worked before (because it was tested) and create it automatically using i.e. migrate.exe. Then you try to do your steps and then test, preferably using different "channel" than EF, that the data is there, that the column is there etc. Just pure SQL through good old ADO.NET is enough here. Because it doesn't need to be versatile, you can create some simple helper(s) that will run the query using the well known Connection-Command-Reader path and return it as a raw data i.e. simple IEnumerable (I did that myself, through dynamic to make super simple.).
My advice is just to keep it simple, nothing fancy and clever. It's just to support testing.
I'm considering Grails for my next project, but I will be given a complete database before I start writing the application around it. I have read that Grails is a domain-centric environment, supporting top-down development, so that does not fit my development mode.
Hence my question: is it possible to write a Grails app around an existing DB structure? What would be the best approach? Can Grails be used without a full ORM, but with a pattern like ActiveRecord? Or are there tools to generate Grails classes from an existing DB schema?
are there tools to generate Grails classes from an existing DB schema?
Grails Reverse Engineering Plugin
Yes Grails can be used without an ORM.
We have written non-GORM domain classes that fetch their data from RESTful APIs without ever going to a permanent storage. So Grails is in no way forcing you to use GORM.
Depending on your legacy DB schema you can either just add params to your GORM classes to fit that schema or you can just write your own data accessors for your database.
Giving further tips / ideas without further information regarding your project and database schema is impossible, so I'll leave it at that :)
i got an old Firebird Database with a lot of content.
Is there an easy way to get the content of this Database without rewriting the tables from Database for an Grails Application?
An example would be nice.
Thank you!
Take a look at GRAG.
From their homepage:
You can use The GRails Application
Generator (GRAG) to get started with
Grails using an existing database. It
will generate Grails domain objects
including constraints and relations.
After generating the domain objects,
you can continue using Grails with all
it's power.
GRAG is a very nice Tool..but it does not fit for Firebird Databases.
Well i just rebuild my Tables and everything works fine. I think this is the best Solution to keep it nice and clean.
Thank you for reading.
Let's say your app enables users to create their own tables in the database to hold their own, custom data. Each table would have it's own schema. What are some good approaches?
My first stab involved dynamically creating migration files and model files bu I'd like to run this on heroku where you can't write to the filesystem.
I'm thinking eval may be the way to go to create and run the migration class and the model class. But I want to make sure the model class exists when a new process of the app is spawned. Can probably do this by storing these class definition with each user as they create new tables and then run through them all at startup. But now it's convulted enough that I may be missing something obvious.
It's probably a better idea not to generate new classes on runtime. Besides all of the security risks, each thread's startup time will be abominable if you ever get a significant number of users.
I would suggest rethinking your app design and aim at generic tables to hold the user's custom data. If you have examples of data structures that users can create we might be able to help.
Have you thought about a non-sql database for those tables? Look at CouchDB - there are several plugins on Github that integrate it with rails. Records in the database are JSON documents, with arbitrary key-value structure. May be perfect for a user-defined schema.
There is (was?) a cool Wiki project, called Informl. It was a Wiki, not just for web pages but for web applications. (Get it? It's informal because it's a Wiki, it's got forms because it is an application, and it's user-generated, thus Web 2.0, which means that according to an official UN resolution it is legally required to have a name which is missing a vwl.)
So, in other words, it was not just about user-generated content, but also user-generated structured data.
They did this by generating PostgreSQL-specific SQL at runtime to create new tables and then have ActiveRecord reload the schemas.
The code is up on RubyForge. It's based on Rails 1.2.3. I guess you could do much better than that today, especially with the upcoming extensibility interfaces in Rails 3.