The purpose of my investigation was to incorporate an ORM into an MVC. I like what rails did mutating the both of them into one. But, I think they choose the worst ORM to do so. I don't like the fact that I'm supposed to design in an app, and roll changes to a db.

First off, Rails doesn't mutate the ORM into an MVC - rails just makes it easy to generate a Model View and Controller classes based on a database table. You don't have to generate each, and in my view the Model classgeneration is probably the most useful.

Secondly, If you don't change the DB, you're free to change the (possibly generated) classes as you see fit, but if you do change a DB table's fields, the model changes automatically with it (via ActiveRecord).

Maybe I'm misinterpreting that part of your post, but I don't really see what you mean there.

Rails makes the ORM an intergal part of the framework. The ORM sucks; hence, by proxy, the framework sucks. That is what I mean.


First off, Rails doesn't mutate the ORM into an MVC - rails just makes it easy to generate a Model View and Controller classes based on a database table.

If the egg comes before the chicken it is anything but "easy." Rails doesn't generate a model, it generates a file for you to statically type the model. Now, before I started this rant, I was unaware of Alzabo, DBIx::Class's Schema::Loader, or Rose::DB, I'm currently setting up Rose::DB and liking it a lot. - And thanks to the monks with info - These frameworks do what you mentioned, "generate a model ... based on a database table." Rails simply adds getter/setter methods for the table. Big deal. In the rails community they teach DRY like it is a religion, and then they make the assumption that every DB lacks constriants, and that every programmer wishes to treat the DB as if it had the feature set of SQL lite, or MySQL 3.2. Every programmer doesn't -- I don't. Furthermore, rails doesn't generate a a Model, View, or Controller based on a database table, it generates them based on the arguement you give to the generator, wheither or not they exist is your problem. (though again, like most ORMs it can transparently add the getter/setters for the instances at run time)

Secondly, If you don't change the DB, you're free to change the (possibly generated) classes as you see fit, but if you do change a DB table's fields, the model changes automatically with it (via ActiveRecord).

You're obviously misguided. ActiveRecord does not change the model to reflect changes in the db, ever. The only thing the model automatically does, is generate </quote> Alright then, change the primary key, change a check constraint, change a foreign key, change a data type. Oh, look, ActiveRecord proves how adaptive it is yet again. In AR if you create a table with an int column, you can rightfully, or wrongfully attempt to insert a string. The following comes from a ruby bot I was writing with a rails interface, my second rails project. Observe:



channel.population = 'foo'
channel.save
[download]

Yields this: UPDATE channel SET "name" = '#debian-uy', "descr" = 'Debian Uruguay | http://debianuruguay.org | Si quieres pegar código: http://debian-uy.pastebin.com/ | Gran Campaña Pro-Mirror: http://debianuruguay.org/node/129', "population" = 0 WHERE pkid = 3

Thats right, I inserted into an int, the value 'foo', and rails converted that to a numeric 0. I once again, did not tell rails to update name, descr, or pkid. I told it to update population and it generated this statement. What a waste, without a .save(), it won't flush the instance, and with a .save() it flushes the object dispite the content, how primitive.


Ruby syntax is clean, it is a fun language, and I look forward to a more advanced framework that is flexible and reflects the richness and cleanliness of Ruby's grammer. Rails isn't it.


Evan Carroll
www.EvanCarroll.com

After looking into and installing Alzabo, I don't see any examples on getting reverse_engineer to work... Do you have any information on it?


Evan Carroll
www.EvanCarroll.com

You need an example? It's just a method. There you go. This creates one schema object based on whatever is in your database.

To read a PostgreSQL database and create a schema that can be used by Alzabo. If you feel like it, it looks like there's a ->runtime_clone method on the Alzabo::Create::Schema object as well. You wouldn't use that for normal runtime but it might be convenient for your maintenance scripts.

my $schema = Alzabo::Create::Schema->reverse_engineer(
    name => ...,
    rdbms => "PostgreSQL",
    user => ...,
    password= > ...
);
$schema->save_to_file; # I forget how the save directory is configured
[download]

Your runtime code:

my $schema = Alzabo::Runtime::Schema->load_from_file( name => ... );

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

define "retarded" ;-)

Slow at learning, or making no attempt at all.
as is the case often with ORMs and database schemas. =/


Evan Carroll
www.EvanCarroll.com

You might be interested in my talk What's Wrong with ORM. I gave it to london.pm back in March and I'm giving it again to GLLUG this coming Saturday. I'll be wheeling it out one last time at YAPC::Europe in August. I really should get round to turning it into an article.

++ Nice slides, in terms of both content and presentation.

I'll expose my ignorance. What is an ORM? What is wrong with the existing ones? And how would you use one?

P.S. anything that just supports one DB with no care for others is probably going to loose opensource support ;) Probably, maybe not though.

Object-Relational Mapping/Manager, I suspect. (I'm used to seeing it as ORML = Object-Relational Mapping Layer.) Basically a layer of code that automates the work of moving data back and forth between in-memory objects and a relational database.