>
> 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...
