Re: Model primarykey
Yes Mr Yellow, I don't understand why core team always say wontfix?! Because it's an important issue for me and many others developers, because that broke the relational model and theory. Additionally, there is a risk for performances. We are using Cake to improve productivity and repetitive tasks, but we are using many other things to reach the same goal, like DbDesigner, UML, Merise... which respect the relational model. So if we always rewrite our database to be suitable for Cake, it's not a joke! We produce web applications which will be ISO or Quality certified, so the Cake hack for Primary Keys and Reflexive Associations could be a restraint for that... I hope this post is understandable and the Cake's community will work to improve that in 2.0 release... Avairet On 25 fév, 02:13, Mr-Yellow [EMAIL PROTECTED] wrote: The responses to tickets relating to this issue in trac usually have wontfix and a short non-explainatory note basically saying piss off and stop asking you don't need this, we know best. -Ben --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
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 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: Model primarykey
On Feb 25, 4:07 am, avairet [EMAIL PROTECTED] wrote: Yes Mr Yellow, I don't understand why core team always say wontfix?! Because it's an important issue for me and many others developers, 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. Let me go a step further and say that there are a lot of things that could be in Cake which would be very useful for me personally, but I have the good sense not to put them there because they're not relevant to *most people*. That's what this is about. Not only are compound primary keys not worth it, but most people wouldn't even make use of them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
On Feb 24, 8:13 pm, Mr-Yellow [EMAIL PROTECTED] wrote: The responses to tickets relating to this issue in trac usually have wontfix and a short non-explainatory note basically saying piss off and stop asking you don't need this, we know best. Well, I'm really sorry you read such a demeaning tone into my messages on Trac. The fact is, whether we know best is not even the point. The point is, we make decisions on what to support and what not to support based on the driving philosophies of this project, and using it essentially necessitates an implicit agreement with those philosophies. The fact is, compound primary keys are really just not requested that often. Even if they were, we've decided it's just not something we're going to implement, because it adds too much overhead in terms of complexity. 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. But that's the beauty of Open Source: I as a core developer don't *have* to implement a particular feature in order for you to use it. If lack of support for compound primary keys is really enough of a pain point for you, patch the code! :-) No one's stopping you. Just don't expect me to take the extra time out of my life to implement a feature which I personally would have no use for, nor likely ever will. Not to mention the fact that, again, the needless complexity that this would add completely undermines the philosophy of the framework. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
So all the threads asking why you can't do compound primary keys are just my imagination then... Cool good to know I'm delusional. -Ben On Feb 26, 12:42 am, nate [EMAIL PROTECTED] wrote: On Feb 25, 4:07 am, avairet [EMAIL PROTECTED] wrote: Yes Mr Yellow, I don't understand why core team always say wontfix?! Because it's an important issue for me and many others developers, 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. Let me go a step further and say that there are a lot of things that could be in Cake which would be very useful for me personally, but I have the good sense not to put them there because they're not relevant to *most people*. That's what this is about. Not only are compound primary keys not worth it, but most people wouldn't even make use of them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
Um.. I fixed some bugs today and provided the patch. The ticket was deleted. So much for open source. -Ben On Feb 26, 12:37 am, nate [EMAIL PROTECTED] wrote: On Feb 24, 8:13 pm, Mr-Yellow [EMAIL PROTECTED] wrote: The responses to tickets relating to this issue in trac usually have wontfix and a short non-explainatory note basically saying piss off and stop asking you don't need this, we know best. Well, I'm really sorry you read such a demeaning tone into my messages on Trac. The fact is, whether we know best is not even the point. The point is, we make decisions on what to support and what not to support based on the driving philosophies of this project, and using it essentially necessitates an implicit agreement with those philosophies. The fact is, compound primary keys are really just not requested that often. Even if they were, we've decided it's just not something we're going to implement, because it adds too much overhead in terms of complexity. 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. But that's the beauty of Open Source: I as a core developer don't *have* to implement a particular feature in order for you to use it. If lack of support for compound primary keys is really enough of a pain point for you, patch the code! :-) No one's stopping you. Just don't expect me to take the extra time out of my life to implement a feature which I personally would have no use for, nor likely ever will. Not to mention the fact that, again, the needless complexity that this would add completely undermines the philosophy of the framework. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
You guys freak me out. I know that CakePHP is a great framework, but if this compound primary key is really that important to you, maybe you should get on the Ruby train. If the framework does not fit your needs, find one that does. I don't see what the big issue is. It's an incovinience. And it's NOT a trivial thing to implement. I really don't understand this whole thing. Before you started your application, didn't you know this feature wasn't implemented? So why start with CakePHP, then complain that a key feature is missing? As nate said, if you want it, take some time and go for it, but the majority doesn't seem to need it that bad, hence it's not in. On Mon, Feb 25, 2008 at 7:55 AM, Mr-Yellow [EMAIL PROTECTED] wrote: Um.. I fixed some bugs today and provided the patch. The ticket was deleted. So much for open source. -Ben On Feb 26, 12:37 am, nate [EMAIL PROTECTED] wrote: On Feb 24, 8:13 pm, Mr-Yellow [EMAIL PROTECTED] wrote: The responses to tickets relating to this issue in trac usually have wontfix and a short non-explainatory note basically saying piss off and stop asking you don't need this, we know best. Well, I'm really sorry you read such a demeaning tone into my messages on Trac. The fact is, whether we know best is not even the point. The point is, we make decisions on what to support and what not to support based on the driving philosophies of this project, and using it essentially necessitates an implicit agreement with those philosophies. The fact is, compound primary keys are really just not requested that often. Even if they were, we've decided it's just not something we're going to implement, because it adds too much overhead in terms of complexity. 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. But that's the beauty of Open Source: I as a core developer don't *have* to implement a particular feature in order for you to use it. If lack of support for compound primary keys is really enough of a pain point for you, patch the code! :-) No one's stopping you. Just don't expect me to take the extra time out of my life to implement a feature which I personally would have no use for, nor likely ever will. Not to mention the fact that, again, the needless complexity that this would add completely undermines the philosophy of the framework. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
This ticket? https://trac.cakephp.org/ticket/4219 For your information that ticket is not deleted, it was closed as need more information. Nate did the right thing by closing the ticket as needmoreinfo: This isn't really enough information to reproduce the issue. Please attach all relevant model files and related schemas. A unit test might also be nice. If I would have seen this ticket, I would have closed it the same way, asking you as a user of this framework to provide more details. -- /** * @author Larry E. Masters * @var string $userName * @param string $realName * @returns string aka PhpNut * @access public */ On Mon, Feb 25, 2008 at 5:55 AM, Mr-Yellow [EMAIL PROTECTED] wrote: Um.. I fixed some bugs today and provided the patch. The ticket was deleted. So much for open source. -Ben On Feb 26, 12:37 am, nate [EMAIL PROTECTED] wrote: On Feb 24, 8:13 pm, Mr-Yellow [EMAIL PROTECTED] wrote: The responses to tickets relating to this issue in trac usually have wontfix and a short non-explainatory note basically saying piss off and stop asking you don't need this, we know best. Well, I'm really sorry you read such a demeaning tone into my messages on Trac. The fact is, whether we know best is not even the point. The point is, we make decisions on what to support and what not to support based on the driving philosophies of this project, and using it essentially necessitates an implicit agreement with those philosophies. The fact is, compound primary keys are really just not requested that often. Even if they were, we've decided it's just not something we're going to implement, because it adds too much overhead in terms of complexity. 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. But that's the beauty of Open Source: I as a core developer don't *have* to implement a particular feature in order for you to use it. If lack of support for compound primary keys is really enough of a pain point for you, patch the code! :-) No one's stopping you. Just don't expect me to take the extra time out of my life to implement a feature which I personally would have no use for, nor likely ever will. Not to mention the fact that, again, the needless complexity that this would add completely undermines the philosophy of the framework. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
I'm with you, we have some production tables that use compound keys. The app is like 5 years old! Oh well, if we ever convert this over, there's this small thing called SQL we'll be using ;) Anyway, it's good to find this out now. On Feb 13, 9:58 am, avairet [EMAIL PROTECTED] wrote: I have asked again my SQL gurus about this hack using in Cake. Their answer is : adding an Id field is possible, but it will result to a sensible performance decrease (I/O bound effect). Hope this help to improve Cake capacities for the future releases... Avairet On 13 fév, 14:25, avairet [EMAIL PROTECTED] wrote: Hello! I've read this discussion and asked question about it to an older DBA, master of Modelisation and SQL theory since 30 years. He says there are a lot of stupidities and many authors need studying Modelisation and Theory before posting... Only one thing: a Primary Key is not equal to Unique not null index! 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? So, temporarily, I will add a dump auto incrementing ID to my relational tables! Avairet On 12 fév, 18:19, Baz [EMAIL PROTECTED] wrote: Here are some interesting discussions: http://groups.google.com/group/cake-php/browse_thread/thread/4a3f44f8.. Bottom line (from what I gather), it was done so to make Cake work easier. I still don't think a lot of people appreciate the fact that Cake does a whole lot! So hey, if I need to add a dump auto incrementing ID, that's what I'm gonna do. On Feb 12, 2008 10:48 AM, avairet [EMAIL PROTECTED] wrote: Hi, I've the same question. Cake will never support compound or multiple primary keys?? Why? How manage this issue? Thanks by advance Avairet On 12 fév, 09:44, Matias Lespiau [EMAIL PROTECTED] wrote: On Feb 12, 2008 3:56 AM, adammc84 [EMAIL PROTECTED] wrote: if the MySql database table my model is 'modeled' from has a primary key that is user_id,posts_id how do i configure that in cake model to use a dual primary key ? Hi adammc84, Cake does not support multiple primary keys. -- Matias Lespiauhttp://www.gignus.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
Now I'm no hardcore PHP developer, but based on things I've seen in CakePHP and from my previous experience with compound primary keys, I can only imagine how difficult this is to implement *correctly*. Everyone is bitching like 3 year olds. CakePHP should support this, well it doesn't, suck it up. There are many options available to you: 1. Find something that does - RoR seems to. 2. Take some time and add it to the framework *correctly* if you think it's a trivial change 3. Stick to normal PHP I'm sorry, but from the tone of these posts I sense nothing but ungratefulness. I, for one, will always appreciate the day that I stumbled onto CakePHP. My Web Development has never been the same. PS: My views and opinions do NOT reflect those of the CakePHP core team in any way. -- Baz L Web Development 2.0 http://WebDevelopment2.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
On Feb 25, 9:23 am, DragonI [EMAIL PROTECTED] wrote: I'm with you, we have some production tables that use compound keys. The app is like 5 years old! Oh well, if we ever convert this over, there's this small thing called SQL we'll be using ;) Exactly. There's nothing preventing you from manually writing SQL and putting it in your model files. Cake's model layer will never completely eliminate the need for writing SQL, nor was it intended to. There will always be edge cases (such as this) where you'll need to drop down to raw SQL. Fortunately, we provide facilities for that as well. On Feb 25, 8:53 am, Mr-Yellow [EMAIL PROTECTED] wrote: So all the threads asking why you can't do compound primary keys are just my imagination then... Cool good to know I'm delusional. All the threads? I count 5. 5 threads out of over 7800 users and over 45,000 posts. So for the record: yes, you are delusional. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
Baz, slight correction: RoR itself does *not* support composite primary keys. Composite primary key support is available in Rails through an *unsupported* third-party plugin. On Feb 25, 9:59 am, Baz [EMAIL PROTECTED] wrote: Now I'm no hardcore PHP developer, but based on things I've seen in CakePHP and from my previous experience with compound primary keys, I can only imagine how difficult this is to implement *correctly*. Everyone is bitching like 3 year olds. CakePHP should support this, well it doesn't, suck it up. There are many options available to you: 1. Find something that does - RoR seems to. 2. Take some time and add it to the framework *correctly* if you think it's a trivial change 3. Stick to normal PHP I'm sorry, but from the tone of these posts I sense nothing but ungratefulness. I, for one, will always appreciate the day that I stumbled onto CakePHP. My Web Development has never been the same. PS: My views and opinions do NOT reflect those of the CakePHP core team in any way. -- Baz L Web Development 2.0http://WebDevelopment2.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
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 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: Model primarykey
On Feb 25, 12:08 pm, avairet [EMAIL PROTECTED] wrote: - 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! Great, I hope you find that it's worth it. - I'm not enough master with it to develop myself this feature, but in some months, why not? Sure, I'm sure there are a few people will find this useful. Open Source is all about scratching your own itch. - I've just said that will be a good idea to implement it in the future releases, to improve the quality of framework. I'd tend to disagree that supporting composite primary keys in the core would improve the quality of the framework. There are many reasons for this, not the least of which is that there are many features not directly related to the database that rely on a single authoritative key to reference a record, so all that functionality is working against the idea of having a multi-column key. As always, feel free to prove me wrong. If you can find an elegant way to solve all those issues, then I'm sure I'll be all for it. - 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 I'll make sure that a note gets into the manual regarding our lack of support for multi-column keys. Thanks for your input. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
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 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: Model primarykey
The responses to tickets relating to this issue in trac usually have wontfix and a short non-explainatory note basically saying piss off and stop asking you don't need this, we know best. -Ben --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
Hello! I've read this discussion and asked question about it to an older DBA, master of Modelisation and SQL theory since 30 years. He says there are a lot of stupidities and many authors need studying Modelisation and Theory before posting... Only one thing: a Primary Key is not equal to Unique not null index! 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? So, temporarily, I will add a dump auto incrementing ID to my relational tables! Avairet On 12 fév, 18:19, Baz [EMAIL PROTECTED] wrote: Here are some interesting discussions: http://groups.google.com/group/cake-php/browse_thread/thread/4a3f44f8...http://groups.google.com/group/cake-php/browse_thread/thread/4a3f44f8... Bottom line (from what I gather), it was done so to make Cake work easier. I still don't think a lot of people appreciate the fact that Cake does a whole lot! So hey, if I need to add a dump auto incrementing ID, that's what I'm gonna do. On Feb 12, 2008 10:48 AM, avairet [EMAIL PROTECTED] wrote: Hi, I've the same question. Cake will never support compound or multiple primary keys?? Why? How manage this issue? Thanks by advance Avairet On 12 fév, 09:44, Matias Lespiau [EMAIL PROTECTED] wrote: On Feb 12, 2008 3:56 AM, adammc84 [EMAIL PROTECTED] wrote: if the MySql database table my model is 'modeled' from has a primary key that is user_id,posts_id how do i configure that in cake model to use a dual primary key ? Hi adammc84, Cake does not support multiple primary keys. -- Matias Lespiauhttp://www.gignus.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
I have asked again my SQL gurus about this hack using in Cake. Their answer is : adding an Id field is possible, but it will result to a sensible performance decrease (I/O bound effect). Hope this help to improve Cake capacities for the future releases... Avairet On 13 fév, 14:25, avairet [EMAIL PROTECTED] wrote: Hello! I've read this discussion and asked question about it to an older DBA, master of Modelisation and SQL theory since 30 years. He says there are a lot of stupidities and many authors need studying Modelisation and Theory before posting... Only one thing: a Primary Key is not equal to Unique not null index! 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? So, temporarily, I will add a dump auto incrementing ID to my relational tables! Avairet On 12 fév, 18:19, Baz [EMAIL PROTECTED] wrote: Here are some interesting discussions: http://groups.google.com/group/cake-php/browse_thread/thread/4a3f44f8.. Bottom line (from what I gather), it was done so to make Cake work easier. I still don't think a lot of people appreciate the fact that Cake does a whole lot! So hey, if I need to add a dump auto incrementing ID, that's what I'm gonna do. On Feb 12, 2008 10:48 AM, avairet [EMAIL PROTECTED] wrote: Hi, I've the same question. Cake will never support compound or multiple primary keys?? Why? How manage this issue? Thanks by advance Avairet On 12 fév, 09:44, Matias Lespiau [EMAIL PROTECTED] wrote: On Feb 12, 2008 3:56 AM, adammc84 [EMAIL PROTECTED] wrote: if the MySql database table my model is 'modeled' from has a primary key that is user_id,posts_id how do i configure that in cake model to use a dual primary key ? Hi adammc84, Cake does not support multiple primary keys. -- Matias Lespiauhttp://www.gignus.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
On Feb 12, 2008 3:56 AM, adammc84 [EMAIL PROTECTED] wrote: if the MySql database table my model is 'modeled' from has a primary key that is user_id,posts_id how do i configure that in cake model to use a dual primary key ? Hi adammc84, Cake does not support multiple primary keys. -- Matias Lespiau http://www.gignus.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
Here are some interesting discussions: http://groups.google.com/group/cake-php/browse_thread/thread/4a3f44f8217435cc/39065d9e99a1c5c1?lnk=gstq=multiple+primary+key#39065d9e99a1c5c1 http://groups.google.com/group/cake-php/browse_thread/thread/4a3f44f8217435cc/3c1ff611e628644c?lnk=gstq=multi+primary+key#3c1ff611e628644c Bottom line (from what I gather), it was done so to make Cake work easier. I still don't think a lot of people appreciate the fact that Cake does a whole lot! So hey, if I need to add a dump auto incrementing ID, that's what I'm gonna do. On Feb 12, 2008 10:48 AM, avairet [EMAIL PROTECTED] wrote: Hi, I've the same question. Cake will never support compound or multiple primary keys?? Why? How manage this issue? Thanks by advance Avairet On 12 fév, 09:44, Matias Lespiau [EMAIL PROTECTED] wrote: On Feb 12, 2008 3:56 AM, adammc84 [EMAIL PROTECTED] wrote: if the MySql database table my model is 'modeled' from has a primary key that is user_id,posts_id how do i configure that in cake model to use a dual primary key ? Hi adammc84, Cake does not support multiple primary keys. -- Matias Lespiauhttp://www.gignus.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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: Model primarykey
Hi, I've the same question. Cake will never support compound or multiple primary keys?? Why? How manage this issue? Thanks by advance Avairet On 12 fév, 09:44, Matias Lespiau [EMAIL PROTECTED] wrote: On Feb 12, 2008 3:56 AM, adammc84 [EMAIL PROTECTED] wrote: if the MySql database table my model is 'modeled' from has a primary key that is user_id,posts_id how do i configure that in cake model to use a dual primary key ? Hi adammc84, Cake does not support multiple primary keys. -- Matias Lespiauhttp://www.gignus.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP 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 -~--~~~~--~~--~--~---
