On 2008-07-28 22:33:44 +0100, Matt S Trout wrote: > > Is there anything speaking against wrapping line 52 of the DBIC > > backend class with an eval to trap this duplicate error and ignore > > it silently (or just warn about it) except the fact that it's > > trying to fix something that probably should be the database's > > task? > > Don't see why not.
Store::DBIC was intended as a drop-in replacement for Store::DBI, for when you want to use the rest of what DBIx::Class gives you in terms of tracking tables, etc. I'd like to keep their behavior in sync, if possible. Currently the method which Store::DBIC uses to find the session and flash rows is very similar to that in Store::DBI, and I believe that Store::DBI has the same race condition. Store::DBI may be "fast enough" by using direct DBI that it hasn't cropped up. For Store::DBIC, I think we should consider instead: (1) updating the docs to discourage usage of MyISAM and other non-ACID setups (2) wrapping each find_or_create call in a transaction to be sure that these race conditions don't happen on real databases (3) making the backend (i.e. delegate) configurable for people who can't use transactions, implementing the alternate functionality However, the last point makes me feel like we're doing something that DBIx::Class normally abstracts. -- Daniel Westermann-Clark _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/