Topic: Wow, this looks cool.... (Dr Nic's Magic Models)

http://magicmodels.rubyforge.org

Has anyone here played with this?  This is looking very nice to me on first glance -- I especially like being able to declare things :null=>false in the migration and having it automatically add the validates_presence_of behind the scenes.

Auto-generating the simple associations seems like a win too, but I'm starting to wonder if removing all this information from the model will make the model harder to understand.  Perhaps using both magic models and the annotated model plugin (ie copies the table definition from the schema.rb to a comment field in the model file would give enough.  Though :has_many :through would be "invisible"....

Any thoughts?

My RoR journey  -- thoughts on learning RoR and lessons learned in applying TDD and agile practices.

Re: Wow, this looks cool.... (Dr Nic's Magic Models)

I've just started playing with it, 15 mins after installing the gem I had all 16 models in my current-app-in-dev working without trouble! amazing stuff

very cool imho because for those of us using migrations it continues the rails philsophy of convention over configuration, I mark :null=>false on all fields that I want validated, so why should I need the tell rails twice (once in migrations & once in model)

but I do agree with you that it makes it harder to understand just by glancing at the code how the model's relationships work - but that's really, if you think about it, stuff that belongs in the documentation no?

Re: Wow, this looks cool.... (Dr Nic's Magic Models)

Baltar wrote:

but I do agree with you that it makes it harder to understand just by glancing at the code how the model's relationships work - but that's really, if you think about it, stuff that belongs in the documentation no?

Well in most cases the code should be the first source of documentation.  Ie, rdoc type systems that try to extract the maximum possible documentable information from the actual code, with descriptive text or additional hints provided by comment blocks associated with the commented entity.  I haven't explored if Rails has extended rdoc to do smart things with documenting has_one/many,etc.  If it does then the Magic Models are completely masking that, which means that your comments and your schema can easily drift as they are defined in different files.  Plus Rails coders seem to be somewhat poor documenters so saying its a documentation problem seems to be the wrong way to go.

I'm also a little skeptical as to the automatic associations deal with being overridden by manual ones -- at least half of mine are normally marked :dependent=>:destroy.  Another half tend to need some degree of customization (:conditions or :class_name, etc) and I worry that the automatic ones could reveal non-intended behavoir.  (If Rails supported foreign keys, then it could derive the :dependent clauses and I'd be happy with only my real customizations...  Of course if rails supported foriegn keys and understood unique constraints, we wouldn't have to write has_one/many,belongs_to at all as all of the associations are discoverable and magic models would probably be the "normal" thing.)

My RoR journey  -- thoughts on learning RoR and lessons learned in applying TDD and agile practices.

Re: Wow, this looks cool.... (Dr Nic's Magic Models)

Great find. It is really amazing what some people can accomplish with plugins.

But, I think I'll stick with adding no limitations to the database side and handling it all on the application side. This way there is really no duplication (except maybe some relations) and the validations and relations are defined all in one place: the model. I think this also allows for more flexibility because, if you need to change the validation, the model is easier to change than the database.

I can definitely see how this can be useful for others though, especially if the database is accessed frequently from outside of Rails.

Railscasts - Free Ruby on Rails Screencasts

Re: Wow, this looks cool.... (Dr Nic's Magic Models)

I'm very torn, but that's nothing new with Rails.  I'm more of a database guy at heart; thus I want to use the DB to its full potential.  I hate artificial/surrogate keys when they aren't needed, I want on update/delete foreign keys.  I like stored procedures.

However I like most everything else about Rails, so I've been trying to do things the rails way.  I've been willing to compromise on the artificial key thing, though I do wish Rails provided a useful way to define candidate keys in the migration -- every non-unary relation should have at least one set of non artificial columns that can uniquely identify a tuple otherwise you're opening yourself up to madness at some point.

I'm slowly coming around on the foreign key issue.  The :dependent=>[possible option types] provides most of the same capabilities as on delete.  The main trade-off is efficiency of the delete, on-delete reduces the query overhead while :dependent=>:destroy has higher query overhead, but makes it easier to hang callbacks on the subordinate objects if needed and :dependent=>:delete_all provides something close to the efficiency of the foreign key approach (one additional query no matter how many subordinate tuples to delete).

I suspect once I've further improved my testing assertions to make it easy to specify which depenent method if any, I'll be willing to abandon the foreign keys in the DB.  Ie, I find it difficult/annoying/cumbersome to remember to test that deleting a container record deletes the subordinate record and doesn't leave an orphan null behind.

The stored procedure issue is another wash to me -- trading off efficiency of the optimized DB code for an easier to scale DB system.  For the size application I think a lot of Rails apps are if they could leverage their DB they wouldn't need to add extra web servers or extra db servers as quickly.  However once the have to worry about db replication, I see how the rails approach tends to win for simplicity.

My RoR journey  -- thoughts on learning RoR and lessons learned in applying TDD and agile practices.

Re: Wow, this looks cool.... (Dr Nic's Magic Models)

The :dependent issue is a good point about the magic_models, one thing that I have found today in playing around with it though is how useful it is for prototyping ideas, maybe it's because I'm still getting to grips with rails, but I've found myself making lots of little test apps recently to try out ideas, and for that this plugin is a god-send since it saves me typing out all the obvious relationship stuff.  I see your points though and think that probablyl for a fully-fledged production app it would be best to stick to typing out the has_many's and belongs_to's

I just kinda like the idea of separating out the model and schema the same way models and business-logic have been split apart, it seems logical to me to have the database schema layout the relationships and what-is-valid for the data, then the model takes care of methods that the 'object' can perform etc, and with the controller and views taking on their familiar roles. Sort of a MVC+D

Re: Wow, this looks cool.... (Dr Nic's Magic Models)

Normally with an activerecord interface you specify the model in the application, and it generates the correct SQL schema by reflecting on that, and loads it into the RDBMS for you (for example, Hibernate). Rails does it the opposite way, by reflecting on the database, which sometimes I kind of like because then I can use my usual data modeling tools (as long as I ignore migrations). But Magic Models wouldn't be necessary if either the database could contain all the information about the model necessary for Rails, or the Rails app could contain all the information about the model necessary for the database. Right now it's a lot of one and a little bit of the other.

Just a thought. That said, if you like Magic Models, also please look at has_many_polymorphs.

Evan