Re: conflicting advice about has_a and primary keys

[prev] [thread] [next] [Date index for 2004/05/18]

Personally, I was under the impression that it works okay to use has_a 
to inflate a column that is part of a multi-column key, but it was a bad 
idea to inflate a single column key (as you might accidentally inflate 
it to itself, which I guess would cause some kind of infinite loop). I'm 
not really sure where I got that impression, so grain of salt and all that.

However, in 0.95 I did run into a particular problem where such columns 
would not, in fact, get inflated in certain circumstances. (As I recall, 
when catching the return value of add_to_*, the returned object's key 
fields were not inflated). I have not yet had a chance to try out 0.96 
to see how things have changed.

Cheers,
Vince

Tony Bowden wrote:

>On Tue, May 18, 2004 at 02:04:22PM -0400, Perrin Harkins wrote:
>  
>
>>The CDBI docs contain this piece of advice in the has_a() section:
>>"*NOTE* You should not attempt to make your primary key column inflate
>>using has_a() as bad things will happen. 
>>A little further down in the many-to-many section, it breaks this rule.
>>Which of these is correct?  Or is it just that using has_a() on your
>>primary key fails if you specify an inflate() method?
>>    
>>
>
>To be honest I'm not sure.
>
>The warning under has_a is there as people reported bad things
>happening.
>
>However, the MCPK linking table thing seems to work.
>
>So, I don't know if the caveat is out of date, or if there's something
>different in the linking table scenario.
>
>Hopefully, however, if I can ever find some time in the increasingly
>surreal corporate soap opera that is currently my life, and get the
>changes finished off so that attributes are objects rather than simple
>scalars, and can thus hold several different pieces of information
>simultaneously (database value, current value, inflated value, etc.)
>we can sort all of this out anyway.
>
>Tony
>  
>