Re: HABTM in rc3 need now field id in link table.
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 cake-php@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: HABTM in rc3 need now field id in link table.
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 cake-php@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: HABTM in rc3 need now field id in link table.
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
Re: HABTM in rc3 need now field id in link table.
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
Re: HABTM in rc3 need now field id in link table.
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 cake-php@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: HABTM in rc3 need now field id in link table.
I did a lot of work and research into this issue of which I thought
martin.westin responded to.
A primary id field is required in order for the current code to work.
I have some changes and test that could be made to the core that would
correct the problems that exist when an id key is not present.
I had posted earlier this month some questions to the core team of how
we should proceed.
Is this not the same problem as this post:
http://groups.google.com/group/cake-php/browse_thread/thread/5d5f3aea37a8b950/c61b3d39e217c2c6#c61b3d39e217c2c6
The problem as I recall it is the delete that is called while doing an
update does not pass the second parameter to the model delete function
for cascade.
Plus if there is no id then it builds a condition based on the wrong
side of the relation. The combination of the to conditions causes all
relations to be dropped except for the one your saving.
I'll check this post again later today to see how we want to proceed,
their were some conversations that took place on the IRC channel in
regards to this and the consensus was the mapping tables need a
primary id key field. So I never bothered with adding my tests and
code changes.
At the very least maybe we should add some code to throw an error or
warning when a mapping table has no id.
On Oct 29, 2: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 cake-php@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: HABTM in rc3 need now field id in link table.
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 cake-php@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: HABTM in rc3 need now field id in link table.
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 cake-php@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: HABTM in rc3 need now field id in link table.
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 cake-php@googlegroups.com
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
-~--~~~~--~~--~--~---
HABTM in rc3 need now field id in link table.
i have a HABTM products-alloweduses
this is the linking table.
CREATE TABLE IF NOT EXISTS `alloweduses_products` (
`id` int(10) unsigned NOT NULL auto_increment,
`allowedus_id` int(10) unsigned NOT NULL,
`product_id` int(10) unsigned NOT NULL,
`value` enum('yes','no','na') collate latin1_general_ci NOT NULL
default 'na',
PRIMARY KEY (`id`),
UNIQUE KEY `uk` (`allowedus_id`,`product_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci
AUTO_INCREMENT=36 ;
if i remove id the edit of product will fail. anyone know about this
bug? there is already an opened ticket?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
CakePHP group.
To post to this group, send email to cake-php@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: HABTM in rc3 need now field id in link table.
I believe that when you have extra fields in a linking table you are
also required to have a primary key. I am not sure if Cake ca handle a
composite pk in this case. I.e. making your unique key into a primary.
/Martin
On Oct 28, 1:53 pm, Alexandru [EMAIL PROTECTED] wrote:
i have a HABTM products-alloweduses
this is the linking table.
CREATE TABLE IF NOT EXISTS `alloweduses_products` (
`id` int(10) unsigned NOT NULL auto_increment,
`allowedus_id` int(10) unsigned NOT NULL,
`product_id` int(10) unsigned NOT NULL,
`value` enum('yes','no','na') collate latin1_general_ci NOT NULL
default 'na',
PRIMARY KEY (`id`),
UNIQUE KEY `uk` (`allowedus_id`,`product_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci
AUTO_INCREMENT=36 ;
if i remove id the edit of product will fail. anyone know about this
bug? there is already an opened ticket?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
CakePHP group.
To post to this group, send email to cake-php@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: HABTM in rc3 need now field id in link table.
in rc2 all worked ok and i had to add some simple code in product
model to work
class AllowedusesProduct extends AppModel {
var $name = 'AllowedusesProduct';
var $useTable = 'alloweduses_products';
function beforeSave(){
$this-id = null;
return true;
}
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
CakePHP group.
To post to this group, send email to cake-php@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: HABTM in rc3 need now field id in link table.
As far as I remember 'id' (or primary key column) was always required
for the join table to work correctly.
Cake doesn't support compound keys, so to ensure uniqueness of the
records the primary column is required.
At any rate it is certainly not a bug.
P.S. Also, cake doesn't support 'enums' out-of-the-box.
On Oct 28, 10:47 am, Alexandru [EMAIL PROTECTED] wrote:
in rc2 all worked ok and i had to add some simple code in product
model to work
class AllowedusesProduct extends AppModel {
var $name = 'AllowedusesProduct';
var $useTable = 'alloweduses_products';
function beforeSave(){
$this-id = null;
return true;
}
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
CakePHP group.
To post to this group, send email to cake-php@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: HABTM in rc3 need now field id in link table.
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 cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
