On Jun 3, 2011, at 4:13 PM, Ramsey Gurley wrote: > On Jun 3, 2011, at 3:53 PM, Chuck Hill wrote: >> On Jun 3, 2011, at 1: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. >> >> I don't see how that is normalizing anything. > > Well, it does keep all the values matching what is in table B. So if table B > has RED, YELLOW, BLUE, and someone decides they want to set the column to > GREEN, it should cry.
That is validation, not normalization. :-) >>> 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. >> >> Wouldn't a simple CHECK constraint be easier? And more sensible? > > > Didn't think about a check (^_^) Granted, this trick doesn't add a lot of > value from an EOF perspective. But it does produce a helpful menu to select > the possible choices in navicat <cough> D2W <cough> > for those who are editing the database manually... (>.<) Ick! Users create enough problems using a UI! > Maybe a check will give me the same benefit without the extra table? I doubt that Navicat is that smart, but it might be. >>> I mention it, because these "clever" hacks of mine usually end up blowing >>> up in my face later on down the road. (^_^) >> >> It is your game, if you break it you get to keep all of the pieces. >> >> >> Chuck > > Hence why I posted. Seems to work so far, but it goes against general WO > wisdom... which means it's most likely a bad idea (^_^) It feels like a lot of effort in the wrong direction to me. But it IS your game. Chuck -- Chuck Hill Senior Consultant / VP Development Come to WOWODC this July for unparalleled WO learning opportunities and real peer to peer problem solving! Network, socialize, and enjoy a great cosmopolitan city. See you there! http://www.wocommunity.org/wowodc11/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
