Re: Order of before_delete trigger in docs

[prev] [thread] [next] [Date index for 2005/06/27]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jun 26, at 10:32 (-0700), 'Bill Moseley' wrote:
> The docs for the delete method say:
>   The "before_delete" trigger is when an object instance is about
>   to be deleted. It is invoked before any cascaded deletes.
>
> Perhaps I'm not understanding the wording, but it seems like the
> trigger is called after the cascaded deletes:
>
> DB::Role->has_many( roles => [ 'DB::PersonRole' => 'role' ] );
>
> DB::Role->add_trigger( before_delete => sub { warn "Role before_delete\n" });
> DB::PersonRole->add_trigger( before_delete => sub { warn "PersonRole before_delete\n" });
>
> my $role = DB::Role->find_or_create( { name => 'Admin' } );
> my $person1 = DB::Person->create( { name => 'Person1' } );
> $person1->add_to_roles( { role => $role } );
> $role->delete;
>
> results in:
>
>    PersonRole before_delete
>    Role before_delete

This should only happen when you also have a reverse relation like:
   DB::PersonRole->has_a(role => 'DB::Role', 'id');

I really doubt this happens "as designed", but that's life. ;-)

I stumbled upon this for many times, so here's a possible workaround: do 
not blindly create "cyclic" relations, but first decide which relation 
it's more important to you (from CDBI point of view, obviously). Then 
create only _that_ relation as the manual says. :)

Let's draw an example over your 2 classes:
   DB::Role->has_many(roles => 'DB::PersonRole', 'role');
   DB::PersonRole->has_a(role => 'DB::Role', 'id');

A) Let's suppose your "Role to Person" is more important:
  - DB::PersonRole->has_a(role => 'DB::Role', 'id');
  + package DB::PersonRole;
  + sub role { DB::Role->retrieve(id => shift->id) };

B) "Person to Role" is more important:
  - DB::Role->has_many(roles => 'DB::PersonRole', 'role');
  + package DB::Role;
  + sub roles { DB::PersonRole->search(role => shift->id) };

As you saw, I just replaced CDBI magic with some lesser magic :)

What does this mean?

The good: workaround for all these magic triggers that occur in
   (IMHO) wrong order
The bad: you lose (in the case of "has_many") the "add_to_*" feature
   (which anyway, it's again very simple to bake without any magic powder)

Check out a related subject here:
   http://wiki.class-dbi.com/index.cgi?DeletingRelatedObjects

cheers.
- -- 
Marius Feraru                                   http://www.altblue.com/
"It isn't easy being the parent of a three-years-old.
  However, it's a pretty small price to pay for having somebody
  around the house who understands computers."
-----BEGIN PGP SIGNATURE-----

iD8DBQFCv1e/n0ZKufYp8iURAlTDAJ9J9vPU//t8QTGSGJgi2BZ4Y2GboACeNZwr
4Ym1GLRTV30crwgFaQUglB8=
=7nLY
-----END PGP SIGNATURE-----