[Dbix-class] possible bug in DBIC:ResultSet?

[Matt S Trout]

Mark Hedges wrote:
>> On Tue, 6 Jun 2006, Mark Hedges wrote:
>>> I didn't look closely.  This is another entity that has a
>>> timestamp DEFAULT CURRENT_TIMESTAMP() as a column of an MCPK.
>>>
>>> I tried adding
>>>
>>>  __PACKAGE__->load_components(qw( PK::Auto Core ));
>>>
>>> to the class package for this entity.  It doesn't help.  Same error.
>>>
>>> Probably because last_insert_id() is looking for an
>>> auto-increment value and doesn't know anything about timestamps.
>>>
>>> I'm going to fake this one using a DateTime->now from the
>>> script instead of trying to use the MySQL server's NOW().
> 
> On Wed, 7 Jun 2006, Jess Robinson wrote:
>> Umm, not sure I understand the restated problem, but if your DB is 
>> auto-filling fields and you want to retrieve them into your row object, 
>> you want to either:
>> write your own component thath overloads insert, just like PK::Auto does, 
>> for those fields
>> or:
>> Call ->discard_changes on your object, after inserting it, which will 
>> update it with values in the DB.
> 
> 
> The problem is that the auto-filled timestamp field is part of the MCPK.
> PK's for a support ticket system are originator e-mail, subject and timestamp.
> 
> If I overload insert, the only thing I have to go on are the two other
> fields of the MCPK.  I could do SELECT...ORDER BY timefield DESC LIMIT 1
> but that wouldn't be guaranteed to be the same row if someone else inserted
> another message in that split second.
> 
> I'm pretty sure discard_changes would behave the same way, since it doesn't
> yet have all the values of the MCPK with which to update it from the DB.
> 
> It is easiest just to pass a DateTime->now() for the field to $rs->create().
> That works fine.

Using timestamps in a PK is almost always a bad idea; I'd just add an 
auto-inc PK and use discard_changes. Indexes better anyway.