On Jun 2, 2010, at 5:36 PM, Kate Yoak wrote:
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:
Let me first say, you need to take a look at Fey::ORM, it is pretty
much exactly what you are looking for.
Also, i think you misunderstood me here:
* 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.
The relational model is in no way outdated, it is still very much a
good thing. However, objects are explicitly connected graphs and
relational DBs are sets of tuples with only implied relationships. In
the past 8 or 9 years there has been a lot of work to try and stuff
object graphs into relational DBs, basically ORMs. Over these many
years it has become clear to a lot of people that the two models are
not really compatible without compromise (the impedance mismatch).
So, its not that there is anything wrong with the relational model for
relational data, only that it is wrong for non-relational data like
hierarchically structured documents (ex: XML, JSON) and object graphs.
* 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.
I disagree on this, Moose models these nicely with metadata, but it
doesn't mean that the shape of that metadata would match the shape of
a relational DB.
* All of the ORMs mentioned above suffer from a) too close to the
db, b) too performance intensive, or c) both
I wouldn't call it "suffering" so much as I would say that all the
ORMs mentioned have some kind of tradeoffs in order to get some kind
of desired feature set and you simply need to decide what features are
most important to you.
ORMs involve compromises and there is nothing wrong with that, but if
you do not need to make those compromises then why would you use a
solution which required you to do so?
- Stevan
