ThanX nate for the clarification about RoR. Now, with that said and avairet's comment, why hasn't this hurt RoR's recognition?
There has been and always will be a compromise between efficiency/performance and ease of development/productivity. It's a never ending struggle. Yep, a DBA will argue many reasons why we need composite primary keys. That's not the issue. The issue is that it is extremely difficult to implement. Also keep in mind that web technologies are not always directly applicable to any and all data sources that you may have lying around the place. Riddle me this: how many people would have preferred this framework remain in a ver. 0.5 state so that composite primary keys could be implemented? No baking, no ajax helpers, no Auth/Email/Security component, because a *few* people wanted composite primary keys? Also, when we talk about the CakePHP core team (correct me if I'm wrong), aren't those just FOUR (4) guys? As nate said, you are totally free to use custom queries... I understand that *some people* are passionate about certain things. But let's be real here. It's not just YOUR framework. It was created with certain things in mind: needs of the masses, ease of use, ease of development, etc. Yes, it's frustrating, but that's the way it is. There are TONS of things I wish MS Word would (would not) do. What say do I have? It was created (for better or worse) for the masses. The beautiful option you have here is that, you can add functionality that you need. If you can add it "elegantly* enough, you can submit it to the core as a patch. If not, just maintain it in your own code base. But to sit and argue with a developer isn't really doing anyone any help. -- Baz L Web Development 2.0 http://WebDevelopment2.com/ On Mon, Feb 25, 2008 at 11:08 AM, avairet <[EMAIL PROTECTED]> wrote: > > > > 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 -~----------~----~----~----~------~----~------~--~---
