>I think we may be getting a bit off track. Are we discussing schools
>of though on db design CakePHP requirements of application
>development?
Both. Again my point is that, uniqueness of records is a necessity and
due to lack of compound key support you need 'id' for cake to function
properly.
If you don't care about that requirement, which is very rare, then of
course you don't need it.
>All your examples of why a separate pk is needed are uses for you in
>your application, not internal to Cake for managing the association.
>Or am I wrong?
well, look at the original problem... without 'id' his edit() feature
didn't work.
there are other examples, where 'id' is needed. a few were brought up
here on the list and IRC channel.
can you get away without 'id'? sure, in some very basic cases, which
are a lot more rare in a real-world app.
but we are talking about developing cake apps, thus i suggest that
'id' is required to make you sleep better at night, and to make cake
work as expected.
there's simply no compelling reason not to use the extra 'id'
column... so why even worry about it?
On Oct 30, 12:13 pm, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> I think we may be getting a bit off track. Are we discussing schools
> of though on db design CakePHP requirements of application
> development?
>
> For the table articles_tags the unique identifier is the combination
> of the two ids. Adding a third field called id and use that as another
> unique identifier is of-course not a big problem. It is just that it
> is suddenly required without prior notice and no real explanation as
> to why. I honestly would like to read about the reasons for the change
> since I am not sure that it is a new intended requirement. Like I said
> before, without some "official" notice of desired change in behavior
> or requirements, any problem is seen as a bug.
>
> All your examples of why a separate pk is needed are uses for you in
> your application, not internal to Cake for managing the association.
> Or am I wrong? I have actually not tried looking at Cake's sql output
> for a join table with an id column. Does Cake write completely
> different queries if it is there? Mine always specifies the two
> "foreign keys", for example when deleting links.
>
> If you use your join tables in reporting then I understand your need
> for an id (and created and modified). But that is different from
> something something that "was always required for the join table to
> work correctly".
>
> I think it is a very good thing that Cake can now support extra fields
> in join tables. That was definitely missed in earlier releases. And if
> an extra id in every join table is the price we pay then that's a
> small price.
>
> On Oct 30, 4:30 pm, teknoid <[EMAIL PROTECTED]> wrote:
>
> > 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
-~----------~----~----~----~------~----~------~--~---
