This has been posted to the DBIC list for discussion last week. Jonathan just to clarify I was not saying create() calls should not throw exceptions I was saying find_or_create() should handle Duplicate Key insert errors better since it supposedly should return an resultset to you if it exists. But there is some discussion on the list about the issue by people a lot smarter than me and I am sure they will have a good solution or explanation for the problem.
Thanks, ------------------------------------------ Ali Mesdaq Security Researcher II Websense Security Labs http://www.WebsenseSecurityLabs.com ------------------------------------------ -----Original Message----- From: Jonathan T. Rockway [mailto:[EMAIL PROTECTED] Sent: Friday, July 27, 2007 8:57 PM To: The elegant MVC web framework Subject: [BULK] - Re: [Catalyst] flash with DBIC session storage On Fri, Jul 27, 2007 at 06:11:03PM -0700, Mesdaq, Ali wrote: > I think in the case of the person who initially emailed the group the > problem is poor load testing. But it does bring up the point of better > handling of exception statements by DBIx. DBIx:: is a generic namespace for DBI extensions. DBIx::Class is abbreviated as DBIC. (This comes up a lot, I should add it to a FAQ or something.) > The DBIx::Class::ResultSet::find_or_create(): call should handle this > exception better because it can happen in tons of different places and > its not always an application or benchmarking issue. What do you think it should do? create failed. Only your app knows what to do in that situation. Maybe you are suggesting that errors be hidden so your app silently loses data? I am not in favor of that. > In high load situations you WILL see this happen. I have a feeling that your app is broken then. I often do dumbass load testing on my apps and don't have any problems with transactions failing unchecked. I really think you should read about transactional isolation and how deadlocks/conflicts are handled by your RDBMS. The Berkeley DB has really good documentation on both of these things, describing both theory and how to avoid common problems with the library itself. SQLite's docs are also good. > To illustrate here is an example: Your DB has a first_name table to > store user first names You get a flood of new people registering and > you normalize their first names to get id's 2 Users have the first > name of Tom which does not exist yet You call > DBIx::Class::ResultSet::find_or_create(): Both calls detect the name > does not exist Both calls insert with one getting this error > > Now there is no real way to handle this in your app unless you do a > lot of concurrency checking or queuing of inserts. Rollback and try again. Your DBMS' docs will tell you about the best strategy for dealing with this case. I'm sure there's a good-enough generic solution... if someone knows it, I would like to hear. Anyway, you should probably continue this thread on the DBIC mailing list instead. DBIC has *nothing* to do with Catalyst. Regards, Jonathan Rockway _______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/ _______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/