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 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 would also be nice to get the ambiguous select thing fixed because that's bitten me a couple of times before too. Where does the SQL construction happen? ~Noel On Sat, Oct 25, 2008 at 4:16 AM, Jess Robinson <[EMAIL PROTECTED]> wrote: > > > On Fri, 24 Oct 2008, Noel Burton-Krahn wrote: > >> DBIx's cascading delete_all (in DBIx::Class::ResultSet) it broken, >> because it deletes the parent table before it deletes the children. >> The database will throw a referential integrity exception when the >> parent is deleted before the children. I've attached a test program >> below. Here's a fixed version in > > This is intentional. DBICs cascade delete / relationship support deletes in > this fashion so that it does not get in the way of your database itself > doing it. > > Either: Let DBIC do the deleting in this way for you, or turn off DBICs > cascading and let your database do it. > > 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/dbix-class@lists.scsys.co.uk > _______________________________________________ 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/dbix-class@lists.scsys.co.uk