On Jun 2, 2010, at 1:09 PM, Shawn H Corey wrote:
On 10-06-02 12:14 PM, Stevan Little wrote:
Primary key and foreign key are meaningless to Moose because that
is not
how objects connect to one another, that is how you imply
relationships
in a RDB. I think perhaps you're too stuck in RDB thinking, keys are
most certainly not a requirement for a decent persistence solution.
This
is also less an issue of Moose and more an issue of the impedance
mismatch between OO and RDB, which at this point seems like a
unsolvable
problem.
I could reply by saying you're too stuck in OO thinking.
And I would agree with you, I personally think ORMs are the wrong tool
for the job because they try and bridge a gap between two very
different conceptual domains. IMO, object graph storage is the better
approach for a "dumb object store".
I will note that you were asking about object persistence and not
relational tuple persistence, so when you imply Moose is lacking
because it does not model relational tuples in the core I felt the
need to reply :)
Meta-data is still data and MVC can be applied to it.
I am not even sure what that means, MVC cares nothing for how your
data is actually stored, the M abstracts that all away.
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.
Anyway, if you want to discuss that I am sure there are plenty of
ideas and experiences that you could mine from the Moose community on
that.
I want a tool that I can apply a DBA view and an OO-programmer view
to a meta-data model.
Then you want an ORM, I suggest either DBIx::Class (if you hate SQL
and/or your DBA) or Fey::ORM (if you love SQL and want to make your
DBA happy).
I would encourage you to look into the impedance mismatch and learn
why ORMs always end in compromise. You might also want to ask yourself
if you really do want an OO view of the data, or an object-oriented
interface to your DB, because those are two *very* different things.
- Stevan
