One of the strengths of Rails and ActiveRecord is that it makes it easy to build your models. You Don’t Repeat Yourself, with your model attributes being derived directly from your database tables. Then all you have in your model definition itself is a discussion of its relationship to other models, relationship to tables and

There are problems introduced by this power however. When writing your application, where is your model definition? Your attributes are generally all in your table definitions. Your models relationship to other models is in your model definition file. Your validations are often in your model, unless your database is performing some form of validation (a practice that is generally encouraged outside the scope of Rails). So they are usually in both places! Plus there’s a good chance in your Rails application that you have introduced at least one or two views to handle things that Rails needs (such as the need for a single column primary key). So now there’s a third place for your model attributes definition.

Rails introduces another way of handling database definition and versioning: rake migration scripts. These are very powerful ways to version and maintain database schemas and data in a product neutral way. But they also spread the definition of “what is the model” out even further. I talk to Rails developers who say “I never look at my database administration tool – I just incrementally edit my Rake migrations”. The problem is that distributes the model definition out even further! It is spread amongst multiple rake migrate scripts.

Many developers used to programming with other tools and environments are also accustomed to some form of graphical frontend to define and manage their database tables. This can be at the “physical level” of tables or at a more conceptual level of entities and relationship (with tools such as ERWin or Visio). Such environments not only ease understanding and ease of manipulation and modify database (and model) relationships but they are also much better at concentrating the model definition into one place.

So here’s my suggestion: An incredibly useful improvement to the Rails app development toolset would be a graphical “model and rake migration designer” frontend. Probably an Eclipse plugin that plays nicely with RadRails (part of RadRails in the future?).

This frontend would allow you to define models, graphically draw relationships between models choosing from amongst the Rails palette of possible model relationships, and generate rake migration scripts from model attribute definitions. It would generate increment rake migrations when model changes were made. It would also allow you to set validations on attributes and models that would be reflected in the model definitions themselves. It would generate migration scripts for join tables when called for by as has_and_belongs_to_many relationship. There are a lot of other features I’d like to see in this tool, but I’ll leave off for now. No, I’m not considering building this. But I and many other Rails developers I know would be delighted by having this tool to use.