-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Zbigniew Lukasiak wrote: > It works only with primary keys. And if you supply 'undef' in > the place of the auto_increment PK then it knows that this will > be a new row. This is an additional convention that I add over > the DBIC semantics - I don't insist that it is elegant but > without it I would have two options: > - an additional parameter to > specify if the operation on a given row is an update or a create > - require that the user adds additional constraints Here's pseudocode for what I do in LFB: # eval{ search for row with PK(s) matching user data PK(s) } # if result is blessed # then user is asking for an update, so do set_columns # else, # user is asking for new row, so do new_result # do update_or_insert. No PK hint is required, here. In the case where there aren't auto-generated PK values, and the user supplies them, then the eval{} still fails, causing a new_result. What scenario is missing from the above, I'd be interested to know ? - -- Oliver Gorwits, Network and Telecommunications Group, Oxford University Computing Services -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI4UtG2NPq7pwWBt4RAmwlAJ4wmQpVjZwbi9yNB/wNZqJi6/vsqACglQxn /Z9wz44Kqbp6KZSbJpmDUK8= =vyLp -----END PGP SIGNATURE----- _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]