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:
-> add relationship to EO1
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. 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?
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
--
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/
|