On Sat, 25 Oct 2008, Noel Burton-Krahn wrote:
Well, delete_all can't work the way its currently implemented if your database enforces referential integrity, and if you do cascading deletes with triggers, you don't need delete_all at all. If that's
If your DB enforces referencial integrity, then it also has a mechanism for cascading deletes. If you wish to turn on one but not the other, you cannot use DBIC with your database, it's as simple as that.
We need to allow databases to do the cascade themselves, (which they won't if we reverse the delete the way you suggest), and we also need to support databases that don't do cascading. That's why the code is as it is, and that's how it will stay.
Unless you can come up with a way to allow both of those, AND your "integrity on but no casacding" scenario.
the way you want to leave things, I'd suggest removing delete_all altogether. I always enforce referential integrity myself, and it is handy to have a function that will recursively delete dependent objects (in the right order, of course), so I would find it more useful to keep delete_all, but fix it so it works with referential integrity.
It wotks fine, just not the way you are expecting, with only some DB-side bits turned on.
Jess _______________________________________________ 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]
