Ramsey, I believe, in this situation, since only one of the properties (the FK) is a class property you should be fine. The problem with class-property FKs is when both the FK and the relationship are class properties and you only set one or the other. In that situation EOF thinks that only one property has actually changed. It isn't smart enough to realize that if one changes, then the other must too. When both relationships and their FKs are class-properties, EOF turns into it's own worst enemy unless if you set one you always, Always, ALWAYS!! set both.
This is doubly true when the FK is a compound key and you can set just one of the FKs, and quadruply bad if that one attribute is part of the compound FK of 3 different relationships! Seriously, I've seen it happen. It's horrific what EOF can do to your data when FKs are modeled incorrectly - or your delete rules for that matter. This is the number-one reason I avoid compound PKs whenever possible. They make it that much easier for little mistakes to bite you in really strange ways. Here's the space where Chuck tells me I'm full of crap: Dave On Jun 3, 2011, at 4:56 PM, Ramsey Gurley wrote: > > On Jun 3, 2011, at 1:20 PM, Chuck Hill wrote: > >> On Jun 3, 2011, at 1:17 PM, Kevin Hinkson wrote: >>> On 3 Jun 2011, at 16:00, Chuck Hill wrote: >>> >>>> There is no need for the first save. Trust in EOF: >>>> >>>>> EO1 -> init >>>>> EO2 -> init >>>>> -> add relationship to EO1 >>>>> -> save both. >>> >>> I thought so, but when I had attempted it once before I got nothing. I >>> figured you were right so the caveat is: foreign keys must not be class >>> properties for this to work. Which makes perfect sense. Thanks again. >> >> >> Correct. You can expose the PK though that is commonly considered Bad >> Practice and Undesirable. Exposing the FK will cause problems for EOF -- >> just don't! :-) >> >> Chuck > > Okay, this is where Chuck tells me I'm a fool... (^_^) > > I've recently decided that this is a good idea: > > I can use wonder's javaEnum prototype to create an attribute on table A. To > ensure that attribute value is normalized in the database, I model that > attribute as the FK in a relationship to table B. Table B has only one > column, the PK, which is the same javaEnum. Now, on table A, I expose the FK > enum as a class property, but the relationship to B is NOT a class property > (^_^) So, with this setup, EOF generates my FK constraint to ensure > normalized data on table A while making it remain by all appearances as just > an enum attribute. > > I mention it, because these "clever" hacks of mine usually end up blowing up > in my face later on down the road. (^_^) > > Ramsey > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
