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

Matt S Trout dbix-class at trout.me.uk
Thu Jun 8 01:56:05 CEST 2006

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.

More information about the Dbix-class mailing list