Re: How to avoid $class->new($value) with inflate

[prev] [thread] [next] [Date index for 2005/03/03]

I agree with you Ofer.

Our code has clumsy special cases that have to interrogate the has_a
rels to distinguish RDBMS-backed relationships from other clever OO
relationships.

In RDBMS theory we have the "domain" of a scalar column value (eg.
Date::Simple) and quite seperately we have relationships to other
entities in the model.    In OO theory we blend these two together.  The
theory's great but it sure would be convenient to distinguish the two
sometimes without having to say ref this and ref that to compare class
names.

frank

>>> Ofer Nave <onave@xxxxxxxxx.xxx> 04/03/05 4:39:46 AM >>>
Perrin Harkins wrote:

>On Thu, 2005-03-03 at 12:08 -0500, Michael Peters wrote:
>  
>
>>Perrin Harkins wrote:
>>
>>    
>>
>>>It's actually not a relationship.  It just maps database values to
and
>>>from local values.  It could even be done as a special accessor.
>>>      
>>>
>>But neither is the case where you use has_a to inflate a date into a

>>DateTime object.
>>    
>>
>
>Sure it is.  That's a relationship between your CDBI object and a
>DateTime object.
>
>- Perrin
>
>  
>
While it's convenient to have CDBI magically use relationships to 
inflate foreign keys into other CDBI objects, I question the wisdom of

piggybacking other forms of inflation upon the same mechanism.  I 
question even the wisdom of inflating CDBI objects using the current 
syntax, since many many people use blah_id as their foreign kay, and 
calling $obj->blah_id() to get the $blah object is nonsesnsical (and
the 
workarounds have problems, too).

It seems to me that the solution is seperating the relationship syntax

from the inflation/conversion/mapping/whatever syntax.  One set of 
methods to define relationships (which are *table relationships*, not 
the relationship between a datetime value and a datetime object) and 
another set of methods to inflate/deflate column values.

-ofer