Dr Nic

Very nice trick Dr. Nic! Very nice trick indeed.

I am very curious on how much of an cost impact this incurs compared to the vanilla AR, but truth be told, it can be made up elsewhere. A Benchmark would be nice to see how much it does impact it though

Definately will be keeping an eye on this project. Congrats.

[Copied from http://www.ruby-forum.com/topic/76331#new because I'm lazy :)]

It uses lazy evaluation - if you send “groups” to a Person object, and that method doesn’t exist already (ie. you haven’t already defined the has_many :groups, :through => :memberships association), then it will build that assocation for you - just as if you’d done it manually in your class definition. Once. Then the method will be there next time.

The only additional performance overhead is the one-time collection of some table and column meta-data via the connection object.

The class creation is similar - if you ask for a constant that doesn’t exist, e.g. Person, then it will look through the table model for a table that might match such a class name, e.g. people, and build the class on top of it. Next time you ask for that class, its already built. Again, its a one-time meta-data request to database.

Ruby is wonderful

I’m now thinking about a Magic Controller that uses something like Dry Scaffolding automatically (http://dry.rubyforge.org/). That’d be snazzy. Instant Rails applications for legacy databases!

How does it handle has_and_belongs_to_many associations?

I stopped using personally when has_many :through came out. I think has_many :through provides the same functionality as habtm (your person object has a groups method, and the group object has a people method).

Except the has_many :through doesn’t care what the join table is called - as long as it has person_id and group_id fields.

But I could be completely ignorant - is there a special circumstance where we’d need to generate a HABTM association?

Pretty nifty; a cool piece of hackery (I mean that in a good way); but ultimately pointless IMO.

Yes, its good to keep things DRY and keep your constraints and associations in one place and in the name of expressive, declrative programming I’d much rather keep them in the model where they belong and use my database as a dumb data store.

Why would I want to view the schema every time I want to know about my model’s constraints and associations?

Finally, as cool as the models without classes trick is, what use is it really? You’re still gonna need the model file unless you’re happy with an anaemic domain model.

The idea came from a legacy db where there were 50+ interconnected tables. We want to build scripts/web apps on top of it, but to not have to write classes + associations until its necessary is very efficient.

MM’s uselessness is troublingly obvious - it doesn’t actually do anything new.

To generate the database you’ll still use the model generator to get the migration and model files; so for new apps you’ll prob never need class generation.

Though I think it fits nicely into DRY and Agile development philosophies that you get the associations and (some) validations without any additional work.

In a way, MM works like scaffolding does at the controller level - it lets you get your application “working” faster even though you’ll probably rewrite it in the end anyway.

Its nice too that it allows you to start writing unit tests straight away that will work, and will continue working whilst you refactor your code and add the explicit associations (which may become more complicated as your application ages).

Another idea on remaining DRY, but having access to schema/association information in the model file could be to extend the annotate_models plugin to generate association descriptions. Currently it only dumps table schema details. With or without the MM in place, this might be a nice feature of annotate_models.

Hey Dr Nic —

We met at RailsConf, if you remember. Anyway, congrats on releasing a plugin to do what so many people have talked about! Awesome.

I’m having problems installing this. It seems to depend on activerecord-1.14.3 while rails depends on activerecord-1.14.4. Any clues on what i should do would be appreciated.

I’ve created a new 0.7.1 version that includes a more flexible dependency on activerecord (now >= 1.14.3).

Thanks for that - made me realise I hadn’t changed the RAILS_GEM_VERSION to ‘1.1.6′ in my test apps, so I wasn’t noticing the problem!

Hi,

Does this system fully support disabled table pluralization? It looks like a fantastic set of time saving, db-driven assumptions. I don’t use table pluralization though and am wondering if I should dig into your code and try to add that or if you’ve already done it?

The forums didn’t seem to reference this aspect at all.

Thanks for any help!

Steve

p.s. Given your predilication for meta-programming, I thought you might enjoy these two recent write ups I did on different kinds of meta-programming:

Redefining methods in Ruby during runtime:
http://www.misuse.org/cms/article.php?story=20060928053416140

Dynamic CSS in Rails:
http://www.misuse.org/cms/article.php?story=20060926084103529

Yep, Magic Models support singular table names, and primary keys with prefixes etc. I use these so I promise they work

Your articles look really good!

Nic

I have often wondered why we need to recreate the model associations when all the information is in the database. This is cool - well done! Have you submitted this as a patch to core? Adding dry scaffolding would be extra cool….

Hi Dr. Nic! thanks a lot for your work, it´s very usefull, very!
I have a wish coult it be posible to add some funcionality for you to add the metadata retrived by the plugin in to the model, or writed in some way?? it could be great dont you think???
thnaks a lot again…
sorry for me english

Any idea how this would play with a PeopleSoft database? PeopleSoft uses composite keys and effective dating which I assume would cause issues for the auto generated rails associations.

I’ve thought about trying to build some rails UI’s to compensate for the atrocious usability of PeopleSoft self service applications, but the thought of defining models for the imense schema has always been daunting.

Ah I just noticed you have another project going to implement composite keys in activerecord. I’ll hav to check into that as well

@wil - you might like to check out the magic_model_generator too as a starting point.

Still, it currently doesn’t look for composite keys, but it could do. I think aiming at getting the CPK gem integrated into the MMG gem is a good idea; feel free to have a go at it - ultimately you need to call the set_primary_keys macro in the class to activate the CPK functionality.

[...] read more | digg story [...]