NaviCat? - I don't use a DB GUI app, but IIRC, NaviCat is for MySQL? If so, you
can just use MySQL ENUM type to constrain a field to specific set of values.
Definition:
ENUM ('RED', 'YELLOW', 'BLUE')
Field size is only 1 byte (when 255 or less enum values in the list)
EOModel Java Type:
String
It will return a sql error if you try to set it to 'GREEN'
Regards, Kieran
(PS. Sending this on a plane, so who knows when this leaves my Outbox)
On Jun 3, 2011, at 7: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.
>
>
>>> 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 for those who are editing the database
> manually... (>.<) Maybe a check will give me the same benefit without the
> extra table?
>
>
>>> 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 (^_^)
>
> 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/kelleherk%40gmail.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]
