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

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

On Fri, 3 Dec 2004, Randal L. Schwartz wrote:
> What I *really* want is:
> 
>        call X when you go from user to object
>        call Y when you go from object to database
>        call Z when you go from database to object
> 
> How do I say that?

I had the same desire. What I did is eschew has_a and drop down to the trigger 
level:

X. Created callback &inflate_from_user and tied it to the triggers 
after_set_$column and before_create

Y. Created callback &deflate_for_database and tied it to the triggers 
before_update and before_create (before create actually calls one callback that 
does &inflate_from_user and then &deflate_for_database)

Z. Created callback &inflate_from_database and tied it to the trigger 'select'.

All my date, datetime and timestamp columns become unix time format (offset 
from epoch) when read from the database. Also, I can feed a unix time value to 
any column, in a new or existing object, and it DWIMs. Or I can feed in a time 
object, and it DWIMs. Then, when the time is fed to mysql, it gets converted to 
the proper format (all three are distinct, IIRC).

Similarly, my text columns are all objects (unless primary keys, obviously), 
and have methods to convert to html, or strip html, or cleanup newlines (crlf 
=> lf etc), etc.

I put all of the logic in my ::DBI class right under Class::DBI. The triggers 
are set up automatically for each class inheriting from my ::DBI class.

This approach feels to me more 'natural' to me than feeding in objects -- BUT I 
set up my triggers so that if an object is passed in by the user, it won't try 
and inflate it, but will just set it in as-is. So I feel I have the best of 
both worlds, at the cost of implementational complexity.