Re: missing the point about mapping from database to object to external rep

[prev] [thread] [next] [Date index for 2004/12/04]

On Fri, Dec 03, 2004 at 05:07:09PM -0500, Perrin Harkins wrote:
> I see what you're asking for.  Class::DBI is all about working with your
> data as objects, so it is geared toward inflate/deflate for that use.
> To do transformations on data without using objects, I would either
> create triggers the same way has_a() does, or just wrap the get/set with
> my own custom methods.

The current plan for all of this, which may or may not help with this
case, is to get the implementation finished whereby all the attributes
of an object are themselves objects, which not only know their current
value, but also what the value last fetched from the database was (thus
simplifying/fixing the is_changed issue, and also separating out the
'raw' value from the 'inflated' value, thus hopefully fixing many of the 
has_a() issues.

As a result of this the code for handling inflation / defalation will
be set up via the Column class (although Class::DBI proper will still
delgate correctly so that nothing needs change for 99% of uses).

i.e. 

	Music::CD->has_a(artist => Music::Artist);

will be translated on the fly into:

	Music::CD->find_column('artist')->inflates_to('Music::Artist');

then the 'artist' Attribute, which knows which Column it relates to,
will be able to DTRT when it needs an inflated value, and also when it
needs a raw value (e.g. for writing back to the database).

This means that it should be possible to hook in better on a column by
column basis to set up your own custom inflation / deflation requirements.


I have this all planned in reasonable detail: it's just a matter of
finding the time somewhere to make it happen.

Tony