> > If perhaps you are looking to automate CRUD using Moose metadata, several > attempts have been made at this and IMO they all ended up with too much > compromise and coupling. You might want to take a look at the Smalltalk > Magritte project, they add an additional layer on top of the pure objects > which provides a more decoupled mapping between the Model and the View. It is > a little more verbose then I would like, but I think they have some good > ideas there. There is also Cocoa and their concepts of bindings, most of > which is accomplished transparently using the Interface Builder app, but the > concepts are pretty sound although a little more coupled then Magritte. >
Oh, this is as good a quote to start off with as any. I am dying to develop a good Moose-based ORM solution and I understand much of the sentiment in this thread, most particularly: * Relational db model is outdated and every database abstraction layer becomes a hacked-up disaster that ages far faster than the other pieces of the system for that reason. * Moose has gone so far in the direction of relationships, delegation - it feels like it should stretch just a tad more, and we'll have a beautiful ORM. * All of the ORMs mentioned above suffer from a) too close to the db, b) too performance intensive, or c) both I have two personal favorites, neither of which is a *good* solution. 1. Class::DBI. (Waiting for laughter to subside. I just use memcache & other tricks to keep my dba happy) It is the most straight-forward object-oriented solution that *feels* as simple as Moose. It has so much of the same kind of spirit. (DBIx::Class added so many features, that at this stage, setting up a simple DB application requires much more than should be necessary. I backed away from it after I was once hired to train a team, because they could not get off the ground using DBIx::Class. This is rather far from "simple things should be simple". ) 2. Rose::DB::Object. This one is infinitely flexible and has some of the same kind of jump-in-and-get-started-then-read-volumes-as-you-get-good-at-it approach as Moose. It is also supposed to be extremely fast, doing crazy db & code optimizations to accomplish it. Unfortunately, there is a comical problem. Rose::DB::Object is designed with a "meta" object that does introspection & clashes with Moose. So the only way to combine those two is an aggregation approach, which can get cumbersome very quickly, or a substantial layer, which resolves the conflict. Seeing as RDBO is already so close to Moose in philosophy, too close as it turns out, my dream is to figure out a way to combine the two and resolve conflicts, of which meta is only the biggest one. Finally, why is it so important to combine Moose with ORM? I love the easy-to-use Model objects that generate pretty easy-to-maintain front end code, e.g. Your mom's birthday is in [% user.mom.birthday.month %] and having all that is required be nothing more than describing the database structure. I really only want to write SQL under unique circumstances that require it, sort of like us perl people don't like using printf to output a blank line. I also want database structure mixed in with other attributes: has_a ('mom' => 'DB::Mom'); #Class::DBI has_many('siblings' => 'DB::Sibling'); has cat => (is => 'rw'...) #Moose Really, just because cat isn't stored in a database is no excuse to put it into some other object. I bet the solution to what I want will look like a trait. package Person; has mom => (traits => ['ORM'], handles => {add_mom => 'create'}, #may be even key => 'mom_id', on_delete => 'cascade', #or for the picky eaters sql_type => 'int', constraint => 'not_null', ) Then we run into how to indicate that Person is an ORM too, so we need a metaclass for it and how to set up the table structure & where, and all these other things. I made the mistake of attempting to create something like this as a first project after discovering both Moose & Rose::DB::Object. Needless to say, it was a miserable failure and set me back a couple of weeks of development. I am still dying to make it happen...