in my MySQL Database, to relate two tables that have an n:n Relation, i use a relational table.
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?
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…
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…
Well, since it was a prototype anyways i for instance changed this design
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
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
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
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:
Discover the correct way to model MANY_MANY relations with Yii (if there is one).
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.
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.