composite primary key not supported by crud command

Hi,

in my MySQL Database, to relate two tables that have an n:n Relation, i use a relational table.

Example

Tasks

  • id

  • name

Folders

  • id

  • name

TasksToFolder

  • taskId

  • folderID

Therefore, in the TasksToFolder, the Primary key is a composite key including both id’s (taskId and folderID). This is not supported by the yiic shell crud command. It returns the Error:


Error: Table "ContentToSite" has a composite primary key which is not supported by crud command.

Should i just set-up an invalid database where the primary key is not taskId and folderId just to be able to work with yii or is there a workarround or a different command or best-practise to manage this?

I’ve got the same problem. This worked fine in 1.0.10 but I can no longer gen the views for a table with a composite primary key.

You can generate the model and the controller (using the model and controller commands respectively in the yiic tool), but crud doesn’t work.

In the guide it states:

I’ve got production databases I can’t change. Can anyone help?

Did you try the method explained in the documentation at:

http://www.yiiframework.com/doc/guide/database.ar

I miss it so much, dont understand why Yii team doesn’t implement it in Yii 1.1…

Hi, I’ve tried defining the primaryKey to return array(‘provider’, ‘language’);

But crud still comes back with the same error.

Error: Table "provider_language" has a composite primary key which is not supported by crud command.

Is this at all possible? Maybe I need to define some relation? Should I forget about it and use a surrogate key?

Thanks for any help.

Qiang is very insistent in not implementing this feature in CRUD command…sincerely, if CRUD doesn’t support composite keys, why do we have CRUD tool if in real world applications we often need composite primary keys in lots of tables? This is just a waste of developers’ time, but the major reason he says is to keep genereted code “simple”…the side effect is that we have a lot more boring and repetitive work because of this “simplicity”

some things I just don’t understand in Qiang’s mind…such a powerful framework with such a gap in an important tool…maybe if hundreds of million people ask for, someday, luckily Yii team will enhance CRUD with this feature…

:)

It might be a big problem if you have an existing database that is hard to alter.

But indeed, if you use it for fast prototyping you just have to take this gap into account when designing your database.

I got arround it by changing my design and i am happy to accept the problems for the benefit i earn using yii.

Though i hope someone will write a good book about it soon since the documentation still is very frustrating.

in my opinion, this is the "wrong" or at least the "worst" way of solving problems because we usually go through against the right relational database modeling definitions and may encounter other problems in the future when we need the relation…

I’m not saying I’m not happy with the framework…if it was the case I’d better to change to another tool hehe :) , I’m just trying to say that Yii or even Yii’s CRUD would be useful if composite key was supported in CRUD, for me, sincerely, CRUD is not that useful at this moment because of this kind of gap…

:)

regards!!!!

Hi,

So, what changes did you make? How did you get around it? Have you got an example?

Thanks.

Well, since it was a prototype anyways i for instance changed this design

  • cityId

  • cityname

  • languagecode

where cityId and languagecode form the composite key (it represents translations for citynames in serveral languages) by spending another id field an putting a UNIQUE index on (cityID, languagecode) to

  • cityLangId

  • cityId

  • cityname

  • languagecode

Now cityLangId is the PRIMARY key, cityId and languagecode are combined in a UNIQUE code and will therefore still be UNIQUE and indexed and that’s all i really needed.

Of course, if i have a Database with thousends of translations and thousends of city names i have a overhead of plenty of Id’s that wouldn’t be neccessary if CRUDF would support composite keys. Still that’s something i accept for the advantages yii brings. I only had to rewrite a few of my question and as far as my calculations go i lose about 39,520 * the size of that additional Id field (4 byte) and that’s arround 160 kbyte and our webserver can deal with that i guess ;D

Though i still would love CRUD support. That’s out of question.

I downloaded Yii because of the CRUD generation mostly, I started following a tutorial and stopped at the CRUD generation part because I have a tables with composite primary key. Now after following a very simple beginners tutorial I see myself on the active records documentation that assumes more knowledge about Yii than the one I have. It’s for a small project so I’m really discouraged upon finding this.

I’m not sure but you can do a small workaround for this.

When generating the model, drop your composite key and let yii generate the model without it, then, after the model is generated, put the composite key back and declare it in the model. This should work just fine though i haven’t tried.

indeed there are some workarounds, but i insist: that’s too much work to do…

even if you generate your CRUD with a single key and after change to a composite key, you’d change by your hands all the generated code…in a small application, with one or two tables with composite key workarounds should work fine…but what if we have lots of tables with composite key and we need to CRUD all of them?

doing that would decrease productivity and in a large scale application, in a real world application, this is a waste of time

because of this, in my humble opinion, CRUD composite keys should be implemented in Gii

:)

regards!

Touché mon ami:)

i solved this problem. but my problem was very simple and i don’t test in another example more complex.

I have only two tables with a relationship one to many. The CRUD with the ‘master’ table work fine, but with the table than have the foreing key don’t work.

The solution.

I create my db with the relationship and when i was make the CRUD i delete the relationship. after created the CRUD i create the relationship again and alter only one line in my code.

In my controller i change the method ‘loadmodel’.

i changed that line

$model=Funcionarios::model()->findByPk((int)$id);

for that

$model=Funcionarios::model()->find(‘fnc_id=:id’, array(’:id’=>$id));

sorry for the english errors. i’m learning yet… =D

If has another solution, please show that to everybody.


Willian Mano

http://www.willianmano.eti.br

@willianmano


Is there any solution to this ? I’ve been using other frameworks for months because of that.

Is anybody can point me to a detailed solution ?

Thank you.

am also having the same problem with the issue of composite key?

may be someone aware about it to help us

I am new to Yii and PHP framework. In which file(s) would I change from a single primary key to a two column composite key? Could you please show how with a simple example of code?

Can someone help - please?

There are so many “MANY_MANY” relationship questions on the Yii forums, not many answers, even fewer examples. Personally I think this is a blocker for mass adoption of the Yii framework. I’m going to buy both of the Yii books that have been published in an attempt to prove myself wrong. `My objectives are simple:

  1. Discover the correct way to model MANY_MANY relations with Yii (if there is one).

  2. Learn how to perform CRUD operations on MANY_MANY models.

This is not "nice-to-have" functionality - it is "must-have" functionality for any PHP framework.

The best effort I’ve seen put forward to compensate for Yii’s deficiencies in the MANY_MANY department is the CAdvancedArBehavior extension: http://www.yiiframework.com/extension/cadvancedarbehavior/

If the implementation of MANY_MANY within Yii’s ActiveRecord architecture is a financial one, then how about some kind of ‘donate’ scheme. I for one would definitely donate (generously) if it would result in implementation of essential “finishing touches”.

It’s a shame that an otherwise near-perfect framework (certainly near-perfect for my purposes) is let down by a few important shortcomings.

I hope that these issues are addressed sooner rather than later.