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

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

On Thu, 2005-03-03 at 09:39 -0800, Ofer Nave wrote:
> 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).

I always have an accessor_name method that strips _id suffixes in my
base class.  I'd like to see an "alias" method of some kind for renaming
single columns quickly, but for stripping _id globally it's much simpler
to just define accessor_name in my base class.  I wouldn't call this a
"workaround."

> 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.

I suppose this all comes down to which things you think are similar.  To
me, object relationships and "inflation" (which is really just a
definition of how you find the related object, given a key) are very
closely tied and belong together.  Applying filters to values on their
way in and out of the database does not seem closely tied to object
relationships.

I think people are getting confused by the fact that this thread started
with a date example, even though it wasn't object-related.  A better
example of what a filter/transform method would be used for is a case
where you have a set of values in your database like 'S', 'M', and 'L'
but you want the accessor for that column to accept and return 'small',
'medium' and 'large' instead.  Many schema designs have situation where
short keys are used in the database but more explicit ones are wanted
for display.  (Maybe this sort of thing should be done in your template,
but that's a separate issue...)

- Perrin