Doesn't even matter so much in terms of cake. It's a simple DB design
issue.
Each record must (should really) have a unique identifier. Considering
cake doesn't support compound (or composite) keys it makes the
'id' (primary key column) necessary.
First example that popped into my head is a reporting Model that needs
to get all associations and report on when a relation between a given
User (which HABTMs) Group was created. How else to retrieve the
records?
What about deleting records?
... and you say that join table may not be accessed directly as a
Model. IMO, that happens a lot more often than not.
In basic scenarios you may get away with two foreign key fields, hence
my original statement: "a primary key column
should be created in a vast majority of cases".
Also, while you can certainly designate a compound key on the DB-
level, it has no affect on your cake app, since cake knows nothing
about them.
Now, all that being said... is there any downside to adding an 'id'
column?
On Oct 30, 4:58 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Sorry to answer a question with a question...
>
> What query would Cake ever need to do to that table where it needed to
> pick out a single row without knowing the two ids (e.g. article_id,
> tag_id)?
> I am of-course talking ab out a "clean" join table. Not one with extra
> fields in it. If you make a unique index (or a composite primary key)
> of the two id fields you prevent duplicate rows and that is all that
> is needed for that table. If, on the other hand, the table has extra
> fields (something Cake has previously not supported) and used as a
> "real" model, then I certainly see the need for a pk.
>
> btw: a composite pk has in my experience never caused any problems. I
> have used that since before 1.0 went stable.
>
> On Oct 29, 8:51 pm, teknoid <[EMAIL PROTECTED]> wrote:
>
> > How else would ensure uniqueness of records if cake does not/will not
> > support composite keys?
>
> > On Oct 29, 3:42 pm, "[EMAIL PROTECTED]"
>
> > <[EMAIL PROTECTED]> wrote:
> > > I don't really agree with the "should" part. For a "standard" join
> > > table I see no reason for an extra id, and I have not noticed of heard
> > > of such a requirement before.
>
> > > Also, when a decision is taken to start requiring a single-field pk in
> > > join-tables I would have expected a bit more of a heads-up about it.
> > > Any new feature that changes the behavior (not halting on an error but
> > > just silently acting differently) of old code will naturally be
> > > thought of as a bug by users if there is no clear indication about the
> > > changed behavior.
>
> > > About the tests: they are usually the place people get directed to to
> > > find out the "true" implementation of any feature. It is also the
> > > standard reply to any bug-report (That the tests pass). So I would not
> > > expect them to be out of date in that way. But it is of-course
> > > possible.
>
> > > If anyone has link to a document on the change in requirement, I
> > > would be grateful. It could be a good read.
>
> > > /Martin
>
> > > On Oct 29, 6:34 pm, teknoid <[EMAIL PROTECTED]> wrote:
>
> > > > Even if those test pass (due to their nature), a primary key column
> > > > should be created in a vast majority of cases.
>
> > > > p.s. It could also be that the tests need to be updated.
>
> > > > On Oct 29, 4:34 am, "[EMAIL PROTECTED]"
>
> > > > <[EMAIL PROTECTED]> wrote:
> > > > > Teknoid, you may be right but the fixtures for the tests in the core
> > > > > create loin tables without a pk.
> > > > > E.g:
> > > > > var $fields = array(
> > > > > 'article_id' => array('type' => 'integer', 'null' => false),
> > > > > 'tag_id' => array('type' => 'integer', 'null' => false),
> > > > > 'indexes' => array('UNIQUE_TAG' => array('column'=>
> > > > > array('article_id', 'tag_id'), 'unique'=>1))
> > > > > );
>
> > > > > /Martin
>
> > > > > On Oct 28, 3:56 pm, Alexandru <[EMAIL PROTECTED]> wrote:
>
> > > > > > no no in rc2 this was on manual
> > > > > > Recipe HABTM Tag => recipes_tags.recipe_id, recipes_tags.tag_id
> > > > > > BUT now they changed in manual and put this
> > > > > > Recipe HABTM Tag => id,recipes_tags.recipe_id, recipes_tags.tag_id
>
> > > > > > now i know for sure it is NOT a BUG.
>
> > > > > > TOPIC CLOSED
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CakePHP" 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?hl=en
-~----------~----~----~----~------~----~------~--~---
