I don't know if these items are bugs, or the behavior by design of the
Cake implementation of HABTM associations, but each took me a while to
figure out. I couldn't find any info on any of these in any of the
documentation sources, so maybe this will help someone.
I'm lazy, so I wanted to take full advantage of Cake's automagic
association and save-to-DB handling, therefore I followed the
recommended conventions all the way through my app. I still had a bit
of trouble, and here's why (I'll try to be brief, and this assumes you
already know something about Cake's HABTM conventions):
Let's say you have a Model 'User', and Users can belong to many Clubs,
and also to many Departments. Further, Users will always belong to at
least one Department, but might not belong to any Clubs. Obviously
Departments and Clubs can have many Users. These are not my models, but
used for simplicity.
When you save a User, you want to be able to automatically write the
appropriate records to the join tables 'clubs_users', and
'departments_users'.
------------------------------------------------------------
Secret 1:
When you attempt to execute User::save($data), your $data array MUST
have the User hash in front of the Clubs and Departments hashs. Meaning
$data must look like:
Array
(
[User] => Array <--- User APPEARS FIRST
(
[fld1] => foo
[fld2] => bar
)
[Club] => Array
(
[Club] => Array
(
[0] => key1
)
)
[Department] => Array
(
[Department] => Array
(
[0] => key1
[1] => key2
)
)
)
If $data is not arranged this way, your save will have unexpected
results. The array order is probably determined by how your forms are
laid out in your view. I found this out by getting very familiar with
the core model code :)...after almost giving up because of conflicting
information in the manual and the wiki regarding foreign key naming
conventions.
I get around this by re-ordering the array to fit the expected form in
my User::beforeSave().
------------------------------------------------------------
Secret 2:
The values for the tables linked to User must be in array form. In
other words, the following will not work:
Array
(
[User] => Array
(
[fld1] => foo
[fld2] => bar
)
[Club] => Array
(
[Club] => key1 <---- SEE THE PROBLEM HERE
)
[Department] => Array
(
[Department] => Array
(
[0] => key1
[1] => key2
)
)
)
This was another fun one to debug. In some cases, maybe some Users can
only belong to one Club - so there is a form somewhere that submits
$data[Club][Club] as scalar value, rather than an array. Again I check
for and fix this in User::beforeSave().
----------------------------------------------------------------
Secret 3
Since Users don't have to belong to any Clubs, your $data array might
look like this on a User::save($data) after a form submission.
Array
(
[User] => Array
(
[fld1] => foo
[fld2] => bar
)
[Club] => Array
(
[Club] => Array
(
[0] => <--- NOTICE A NULL VALUE HERE
)
)
[Department] => Array
(
[Department] => Array
(
[0] => key1
[1] => key2
)
)
)
This can have disatrous effects, because the save() appears to work
without Cake complaining, BUT the keys for Departments are placed in
the clubs_users table, or vice versa, corrupting your data This one
looks like a bug to me, some kind of index gone awry in a loop
somewhere, causing values to get shifted. Again, I do a clean up in
beforeSave() to work around it.
Hope this helps someone, and if anyone sees something wrong with my
thinking, please let me know.
Cheers.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---
