Jeff,
Couple of comments ...
The "." seperator for types is not recommended anymore, instead it is
recommended to use "::" like in normal Perl namespaceing (It was
really only Rolsky that was doing it anyway and even he has switched
to "::" now).
I do not think that the MooseX:: namespace is appropriate for this,
you are not really extending Moose as much as you are making an ORM-
like thing that uses Moose heavily. We are trying to be more
discerning about what goes into the MooseX:: namespace lately because
too many people have used it incorrectly (and yes, I am the worst
offender of this).
and a few questions ...
Echoing Chris Prather's comment, what does this provide over and above
something like KiokuDB using the DBI backend? Or Fey::ORM? or
DBIx::Class?
How do you plan on handling inheritance? what about multiple
inheritance? Based on a review of your tests, it seems that you would
have to map each new level of inheritance to a new table. Now, this is
a common limitation of some ORM systems, but it is handled cleanly by
KiokuDB.
Do you support roles? what about runtime role composition? Again,
these things are a little hairy with traditional ORMs, but KiokuDB
handles them fine.
- Stevan
On Aug 4, 2009, at 3:42 PM, Jeff Hallock wrote:
Please find this module at http://github.com/jhallock/MooseX-DBI/tree/master#
<http://github.com/jhallock/MooseX-DBI/tree/master> (for now).
I'm just looking for some feedback before I send this off to CPAN.
It is a module that works with DBI to store and retrieve objects
from a database. When storing objects have objects that implement
MooseX::DBI as attributes - the value is stored is the primary key
of the object. When restoring objects from the database - the
opposite is true, MooseX::DBI will load the object data from the
database and instantiate it.
It is also possible to specify custom inflators and deflators for
other kinds of objects and data types.
subtype 'My.Date'
=> from 'DateTime';
inflate 'My.Date'
=> via { DateTime::Format::SQLite->parse($_) };
deflate 'My.Date'
=> via { $_->ymd };
has 'date_attribute' (
is => 'rw',
isa => 'My.Date'
);
I'm not stuck on the inflate and deflate methods as the sugar to
perform the flattening/instantiation. It's seems appropriate to
change them to something else, to keep the inflate and deflate words
open for use in a serialization module - where inflate would create
an object from a stored format, and deflate would turn an object
into a particular format.
Originally when I started making this module - It was an extension
on to MoooseX::Storage which is a serialization package. I then
moved to making it part of a new serialization package
MooseX::Serialize because of some limitations in the MooseX::Storage
design (namely, I wanted to be able to use multiple engines at once
- what if someone wanted to primarily serialize to a DBI, but would
also like to create XML files to send out).
So once I had MooseX::Serialize and MooseX::Serialize::DBI in the
works inflate and deflate came into play - and their role was to
serialize/restore a data structure/object from a specified format,
where to be used more like this:
inflate 'My.Date'
=> via { date_obect_from_xml_string($_) }
=> from 'XML';
inflate 'My.Date'
=> via { DateTime::Format::SQLite->parse($_) }
=> from 'DBI';
deflate 'My.Date'
=> via { date_object_to_xml_string($_) }
=> from 'XML';
deflate 'My.Date'
=> via { $_->ymd }
=> from 'DBI';
So, then I abandoned the idea of creating another serialization
package for a couple of reasons:
1. One already existed
2. It was beyond the scope of what I really wanted to do,
which is a package to serialize/to from a DBI object
3. By using MooseX::DBI and MooseX::Storage - one can
serialize the same object to a database and another format
4.
So that is where inflate and deflate come from - should I change
them, if so, what to?
Also, please feel from to comment on any part of the module - I
would like to hear some feedback and make any significant changes
before the first release on CPAN - I don't want to be stuck with
something later because it wasn't thought through now. Please feel
free to write test cases as well as suggest features.
Thank you fellow Moosers!
-Jeffrey Hallock
