RE: Quick $obj->delete qn where obj has multiple primary keys

[prev] [thread] [next] [Date index for 2005/07/01]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57E0A.4FF1F4B9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


> As far as I know delete() works just fine for multi-column=20
> primary keys.
> If it didn't I expect a lot of people would have been=20
> screaming by now.

I've attached a demonstration script that will create a sqlite file
called 'test.sqlite' in the current working directory. Run it with no
arguments for a successful run, with any arguments for the fail case.

The setup in question is a link table and as far as I can tell the same
as the many-to-many Actor, Film and Role example in the docs.

The only difference is that I have changed the string overloading on the
Actor and Film classes to be a nicer "name" field like so:

__PACKAGE__->columns (Stringify =3D> qw/name/);

This addition causes things to break occasionally. Things behave
differently depending on whether the relationship already exists in
Roles or whether it is being created along the way. The following code
doesn't work if find_or_create() found a pre-existing entry:

$r =3D Role->find_or_create( actor =3D> $actor, film =3D> $film );
# if the above created the entry in the DB then the below will work
# if the above retrieved an existing entry from the DB then it won't
delete it here
$r->delete;


The has_a() documentation mentions that the objects are deflated by
stringification unless the deflate method is specified so I thought
adding an explicit deflate() for all relationships that involve modified
stringifications might fix up the weirdness but no.

Would this be an example of the bad things described in the note at the
bottom of the has_a() section: "Note: You should not attempt to make
your primary key column inflate using has_a as bad things will happen"?

How have other people directly manipulated a link table like this?

I'm guessing at this point that I either:

 1. Change things in my application to call my own stringification
    method rather than relying on a modified override and proceed
    as normal.

 Or

 2. Have my own manipulation methods in all my link classes to do
    operations like delete.

Any advice is welcome.

Cheers,

- ao

------_=_NextPart_001_01C57E0A.4FF1F4B9
Content-Type: application/octet-stream;
	name="cdbi_delete.pl"
Content-Transfer-Encoding: base64
Content-Description: cdbi_delete.pl
Content-Disposition: attachment;
	filename="cdbi_delete.pl"

IyEvdXNyL2Jpbi9wZXJsIC13CgpwYWNrYWdlIE15OjpEQkk7CnVzZSBiYXNlIHF3KENsYXNzOjpE
QkkpOwpfX1BBQ0tBR0VfXy0+YXV0b3VwZGF0ZSgxKTsKX19QQUNLQUdFX18tPmNvbm5lY3Rpb24o
ICdkYmk6U1FMaXRlOmRibmFtZT10ZW1wLnNxbGl0ZScsJycsJycpOwoKcGFja2FnZSBNeTo6TGlu
a1ZlbmRvckNvbnRhY3Q7CnVzZSBiYXNlICdNeTo6REJJJzsKX19QQUNLQUdFX18tPnRhYmxlKCds
aW5rX3ZlbmRvcl9jb250YWN0Jyk7Cl9fUEFDS0FHRV9fLT5jb2x1bW5zKCBQcmltYXJ5ID0+IHF3
L3ZlbmRvciBjb250YWN0LyApOwpfX1BBQ0tBR0VfXy0+aGFzX2EoIGNvbnRhY3QgPT4gJ015OjpD
b250YWN0JywgZGVmbGF0ZSA9PiAnaWQnICk7Cl9fUEFDS0FHRV9fLT5oYXNfYSggdmVuZG9yID0+
ICdNeTo6VmVuZG9yJywgZGVmbGF0ZSA9PiAnaWQnICk7CgpwYWNrYWdlIE15OjpWZW5kb3I7CnVz
ZSBiYXNlICdNeTo6REJJJzsKX19QQUNLQUdFX18tPnRhYmxlKCd2ZW5kb3InKTsKX19QQUNLQUdF
X18tPmNvbHVtbnMoIEFsbCA9PiBxdy9pZCBuYW1lLyApOwpfX1BBQ0tBR0VfXy0+aGFzX21hbnko
IGNvbnRhY3RzID0+IFsgJ015OjpMaW5rVmVuZG9yQ29udGFjdCcgPT4gJ2NvbnRhY3QnIF0gKTsK
CnBhY2thZ2UgTXk6OkNvbnRhY3Q7CnVzZSBiYXNlICdNeTo6REJJJzsKX19QQUNLQUdFX18tPnRh
YmxlKCdjb250YWN0Jyk7Cl9fUEFDS0FHRV9fLT5jb2x1bW5zKCBBbGwgPT4gcXcvaWQgbmFtZS8g
KTsKX19QQUNLQUdFX18tPmhhc19tYW55KCBjb250YWN0X2Zvcl92ZW5kb3JzID0+IFsgJ015OjpM
aW5rVmVuZG9yQ29udGFjdCcgPT4gJ3ZlbmRvcicgXSApOwoKCnBhY2thZ2UgbWFpbjsKCnVzZSBE
YXRhOjpEdW1wZXI7CgojIGJsb3cgYXdheSB0aGUgdGFibGVzIGFuZCBzZWVkIHNpbXBsaXN0aWNh
bGx5Cm15ICRkYmggPSBNeTo6REJJLT5kYl9NYWluOwpldmFsIHsKICAkZGJoLT5kbygiZHJvcCB0
YWJsZSAkXyIpIGZvcmVhY2ggcXcodmVuZG9yIGNvbnRhY3QgbGlua192ZW5kb3JfY29udGFjdCk7
Cn07CiRkYmgtPmRvKCdjcmVhdGUgdGFibGUgdmVuZG9yICggaWQgaW50ZWdlciBwcmltYXJ5IGtl
eSwgbmFtZSB0ZXh0ICk7Jyk7CiRkYmgtPmRvKCdjcmVhdGUgdGFibGUgY29udGFjdCAoIGlkIGlu
dGVnZXIgcHJpbWFyeSBrZXksIG5hbWUgdGV4dCApOycpOwokZGJoLT5kbygnY3JlYXRlIHRhYmxl
IGxpbmtfdmVuZG9yX2NvbnRhY3QgKCB2ZW5kb3IgaW50ZWdlciwgY29udGFjdCBpbnRlZ2VyICk7
Jyk7CiRkYmgtPmRvKCJkZWxldGUgZnJvbSAkXyIpIGZvcmVhY2ggcXcodmVuZG9yIGNvbnRhY3Qg
bGlua192ZW5kb3JfY29udGFjdCk7CiRkYmgtPmRvKCJpbnNlcnQgaW50byB2ZW5kb3IgdmFsdWVz
ICgxLCAnVmVuZG9yIDEnKTsiKTsKJGRiaC0+ZG8oImluc2VydCBpbnRvIGNvbnRhY3QgdmFsdWVz
ICgxLCAnQ29udGFjdCAxJyk7Iik7CiRkYmgtPmRvKCJpbnNlcnQgaW50byBsaW5rX3ZlbmRvcl9j
b250YWN0IHZhbHVlcyAoMSwxKTsiKTsKCm15ICRmYWlsID0gc2hpZnQ7CmlmICgkZmFpbCkgewog
IE15OjpWZW5kb3ItPmNvbHVtbnMoIFN0cmluZ2lmeSA9PiBxdy9uYW1lLyApOwogIE15OjpDb250
YWN0LT5jb2x1bW5zKCBTdHJpbmdpZnkgPT4gcXcvbmFtZS8gKTsKfQoKbXkgJHZlbmRvciAgPSBN
eTo6VmVuZG9yLT5yZXRyaWV2ZSggMSApOyAgIyBuYW1lID0+ICdUZXN0IFZlbmRvciAxJwpteSAk
Y29udGFjdCA9IE15OjpDb250YWN0LT5yZXRyaWV2ZSggMSApOyAjIG5hbWUgPT4gJ1Rlc3QgQ29u
dGFjdCAxJwoKbXkgJGxpbmsgPSBNeTo6TGlua1ZlbmRvckNvbnRhY3QtPmZpbmRfb3JfY3JlYXRl
KCB2ZW5kb3IgPT4gJHZlbmRvciwgY29udGFjdCA9PiAkY29udGFjdCk7Cndhcm4gRHVtcGVyKCdP
cmlnaW5hbCBvYmplY3Q6JywkbGluayk7CgojTXk6OkxpbmtWZW5kb3JDb250YWN0LT5kYl9NYWlu
LT50cmFjZSgxKTsKJGxpbmstPmRlbGV0ZTsKI015OjpMaW5rVmVuZG9yQ29udGFjdC0+ZGJfTWFp
bi0+dHJhY2UoMCk7Cndhcm4gRHVtcGVyKCdEZWxldGVkIGxpbms6JywkbGluayk7CgpNeTo6TGlu
a1ZlbmRvckNvbnRhY3QtPmNsZWFyX29iamVjdF9pbmRleCBpZiAkZmFpbDsKCiRsaW5rID0gTXk6
OkxpbmtWZW5kb3JDb250YWN0LT5yZXRyaWV2ZSh2ZW5kb3IgPT4gJHZlbmRvciwgY29udGFjdCA9
PiAkY29udGFjdCk7Cndhcm4gRHVtcGVyKCdUaGlzIHNob3VsZCBiZSB1bmRlZjonLCAkbGluayk7
Cg==

------_=_NextPart_001_01C57E0A.4FF1F4B9--