> That's exactly what I've been saying from the beginning. The > difference is, one is an application key which has meaning within the > context of the application itself, and one is a business key which > satisfies some business requirement.
OK Nate, but a mapping layer must reconciliate logic and business not to impose one to the other... And my sentence was about the old discussion cited by Baz in the firsts posts where a guy said this is the same thing! > Well, if you think this is an easy thing to do, then go for it. Sorry, I've never said that's an easy thing to do! But if you don't implement a thing, just because it's complex and you don't use it, it's really damage... It's harm the framework and it's team recognition... > You can argue about relational theory all you want, it's > simply irrelevant to the decision-making process here. When it comes > down to it, supporting multi-column primary keys is just not that >useful to *me*. Furthermore, not enough people have raised it as an > issue in order for me to go out of my way for them. > I hope you now understand from my comments above that whether or not > it's an issue for you personally is completely irrelevant. > It's not an issue for me personally, and it's not an issue for most people. Yes Nate, I understand now that's your choice! But there are a lot of posts in this Google groups and some tickets in trac about this problematic. In brief: - I'm using CakePHP even if I must rewrite a lot of my tables and relations in my database schemas, because like you say it has many other useful functionnalities! - I'm not enough "master" with it to develop myself this feature, but in some months, why not? - I've just said that will be a good idea to implement it in the future releases, to improve the quality of framework. - I understand it's hard for you to always repeat the same thing, but keep cool with new members of community, because this problematic is not written on documentation/manual/API BR Avairet a simple stupid French guy ;o) On 25 fév, 14:21, nate <[EMAIL PROTECTED]> wrote: > On Feb 13, 8:25 am, avairet <[EMAIL PROTECTED]> wrote: > > > Only one thing: a Primary Key is not equal to Unique not null index! > > That's exactly what I've been saying from the beginning. The > difference is, one is an application key which has meaning within the > context of the application itself, and one is a business key which > satisfies some business requirement. > > > I'm agree with you : Cake doesn't a whole lot! > > But it will better if it respects some basical rules, like compound > > PK... isn't it? > > Well, if you think this is an easy thing to do, then go for it. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" 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 -~----------~----~----~----~------~----~------~--~---
