Re: patch for has_a() on primary keys

[prev] [thread] [next] [Date index for 2005/05/27]

--On May 27, 2005 3:58:39 PM -0400 Perrin Harkins <perrin@xxxx.xxx> wrote:

> On Fri, 2005-05-27 at 15:01 -0400, Charles Bailey wrote:
>> I think there are a few edge cases that need to be covered.  I've
>> attached  the patch I posted last year to do this
>
> I'm not really following the reasoning behind most of these changes.
> Why did you move the select trigger from _flesh() to get()?  And does

Sorry; that's really unrelated.  IIRC, I'd been working on separating out 
database-query code from object-model code, so I'd moved the inflation into 
get().  It's not a functional change, though, so I probably should've just 
dropped it from the posted patch.  That's what I get for just pulling it 
off the shelf in two free minutes.

> this patch address the problem that mine was aimed at, i.e. calling
> create() with scalar values for a primary key column with a has_a() on
> it will result in the accessors returning the scalars instead of
> objects?

It should do the trick via the call to the 'inflate' trigger in _create().

>> and I think it "rolls back" deflation in a few failure cases that
>> the straightforward patch doesn't cover.
>
> What's the use case for trying to re-inflate objects after a database
> exception is thrown?  Is this for dupe key checks?

The idea was that if the caller intends to recover from exceptions (dupe 
keys being a good example), it shouldn't get a broken object back, 
especially since having scalars where the caller left objects invites a 
fatal "Can't call method \"foo\"" error when the caller tries to access 
methods through them.

I hope this helps clear up some of the confusion the original posting 
created.  It was very sparse on explanation, since I only had a couple 
minutes between tasks.

--
Regards,
Charles Bailey  < bailey _at_ newman _dot_ upenn _dot_ edu >
Newman Center at the University of Pennsylvania