Hope this will be good enough :)
(see patch in attachment)
--
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)
Index: lib/DBIx/Class/ResultSet.pm
===
--- lib/DBIx/Class/ResultSet.pm (revision 5021)
+++ lib/DBIx/Class/ResultSet.pm (working
Noel Burton-Krahn wrote:
On Sun, Oct 26, 2008 at 1:19 AM, Peter Rabbitson [EMAIL PROTECTED] wrote:
1) You call delete_all
2) You traverse the entire relationship chain, and start calling delete
on the resulting three backwards, depth first.
3) By the time you get to the main row that you
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,
On Sun, 26 Oct 2008, Noel Burton-Krahn wrote:
Can you rephrase this second issue you are talking about, without
referring the the first one (which is ENOPROBLEM).
If you construct a sufficiently complex select_related clause, DBIx
will construct ambiguous SQL. Take a look at the SQL that
On Fri, Oct 24, 2008 at 04:48:02PM -0700, Noel Burton-Krahn wrote:
Hi Peter,
The problem goes a little deeper: I applied this change to SVN, and
immediately saw the 60core.t unit test fail doing deep recursion.
Apparently this will break when there's a loop in the relationship
graph. So,
On Fri, Oct 24, 2008 at 02:26:35PM -0700, 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
On Sun, Oct 26, 2008 at 1:19 AM, Peter Rabbitson [EMAIL PROTECTED] wrote:
1) You call delete_all
2) You traverse the entire relationship chain, and start calling delete
on the resulting three backwards, depth first.
3) By the time you get to the main row that you wanted to delete_all in
the
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
Hi Peter,
The problem goes a little deeper: I applied this change to SVN, and
immediately saw the 60core.t unit test fail doing deep recursion.
Apparently this will break when there's a loop in the relationship
graph. So, to avoid the loop, I made a version of delete_all which
has loop
