OK, so different roles get a different "Profile" so like earlier Buyer and Seller tables have completely different fields so that’s why I separate them.
When I create a User I create the respective "Profile" either Buyer or Seller record for that user. User.id => UUID and use that as the Buyer.user_id saveAll(). That’s why they are the same. My question is why do I need both Buyer.id and Buyer.user_id? I am not concerenced with them matching or anything I just built the entire app and not once did I query Buyer.id So im just not seeing why its so important to have both. Create User which make Buyer / Seller and each have different various hasmany / HABTM relations. Those relations all call back on Buyer.user_id so where is Buyer.id ever used? Sure it wont kill me to add in both Buyer.id and Buyer.user_id so it links Buyer and User but as far as I can see its never used. I guess I just see Buyer and Seller as an extension of User with different fields based on the Role which makes then one or the other so why give it another UUID when it’s the same thing? Obviously im looking at this wrong so I will follow what it says.... it works for me as I set it up but needless to say if adding 1 field to follow the rules I will just do so and not worry about why...as long as it works is reason enough for me. Just curious Thanks. Dave -----Original Message----- From: cricket [mailto:[email protected]] Sent: November-25-10 10:41 PM To: [email protected] Subject: Re: Foreign Key Cookbook Confusion On Thu, Nov 25, 2010 at 8:40 PM, Dave Maharaj <[email protected]> wrote: > The cookbook states for foreign key “foreignKey: the name of the foreign key > found in the other model. This is especially handy if you need to define > multiple hasOne relationships. The default value for this key is the > underscored, singular name of the current model, suffixed with ‘_id’. In the > example above it would default to 'user_id'.” > > > > Default value meaning that’s is what is suggested to use? > > > > All my id’s are UUID CHAR(36) so building this app User.id is say > 1111-1111-1111-1111 (just so its easier to read for the sake of this > question instead of a real UUID) > > > > When a User is created I make the Profile at the same time using the User.id > so they are the same > > > > User has a Profile so Profile.id = 1111-1111-1111-1111 with Profile.user_id > = 1111-1111-1111-1111 No way. You're looking at this as if you're using auto_increment *and they just happen to coincide*. Sure, that happens sometimes, but it's irrelevant. The PK for a given table is completely separate from that of any other table. But where you've really gone wrong is assuming that a UUID would be the same. They shouldn't be, unless you've got something really wrong with the code that's generating them. Not only should there not be the same UUID found within a given table, but it shouldn't appear again in the same database. In any case, ask yourself if you really need a separate profiles table. Couldn't that data be kept in the users table? Why separate it? Unless your users can have multiple profiles, I don't think it's necessary. Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" 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 Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" 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
