I don't think there is any perfect approach. Strings? how hard is an
update statement in SQL to find occurences of that string and update
it?
I can live with that.
and I love the caught up in their undewear phrase. Matt++
On Thu, Jul 17, 2008 at 1:05 PM, Matt Lentzner <***@gmail.com> wrote:
>
> Robert,
>
> I agree with you that storing a String value is nice as far a db readability
> goes, but there are other costs with that approach besides storage that I
> did not cover. When you say "String" you're really talking about the name
> property. As soon as you store that in the database then you cannot easily
> refactor that name value. We all know that the rename refactor is the most
> common kind of refactoring - so that would bite you sooner or later. It
> conflates the representation of the object in the database with the name it
> has in the code. This is similar to using the ordinal value (although I
> admit, not nearly as bad).
>
> There's a reason that foreign keys are abstract row ids. People have tried
> other approaches and got seriously caught up in their underwear. Maybe the
> essence of Enums makes that kind of concern unrealistic, but I would want a
> solution that is as general as possible, but keep in mind that we are, in
> essence, storing pointers. It violates database normalization as well as
> DRY.
>
> There also a question of data integrity. Int fields can be easily set so
> that no illegal values can be entered. A String on the other hand could have
> all sorts of illegal values put in it and there's no way to enforce data
> integrity at the database level. I know some (not all, AIUI) databases
> support enums, but then you're dealing with the vagaries of different db
> vendors instead of the general case. I personally don't want to go there.
>
> I like the getId() call because it is abstracted, efficient, and should be
> easy to retrofit. I would think that Grails could just intercept the ordinal
> call from Hibernate and you're done. Hacky, yes, but fairly non-invasive. I
> wouldn't be averse to having a String based option to store the enum as
> well, but now we're getting into a lot of new code and possible
> kitchensinkism.
>
> My final remark is that your example of regressing back to int const enums
> is a red herring. The problem wasn't that they were ints, but that they were
> not type safe. You could have enums as Strings and the problem would be no
> different (with additional problems included). Once you store a value in the
> database you lose all type safety anyway so a int is not different from a
> String in that regard. The sole benefit to storing the String is db
> readability. I think the price tag on that benefit is rather high.
>
> Regards,
>
> Matt
>
>
> Robert Fletcher wrote:
>>
>> That smacks to me of premature optimisation. Is it really such an
>> issue to have enums stored as String values? From a purist point of
>> view, sure it's somewhat wasteful but I'd argue that's considerably
>> outweighed by the convenience and simplicity. Most enum names tend to
>> be pretty short. Plus it makes the results of any database queries you
>> may do directly considerably more readable. Using assigned int values
>> for enums seems like a half-step back towards the int constant
>> anti-pattern enums were introduced to solve in the first place. If
>> storing the same string multiple times is really a concern you could
>> always promote the enum to a simple GORM class and use a one-to-one
>> association.
>>
>> Cheers,
>> Rob
>>
>> On Wed, Jul 16, 2008 at 7:01 PM, Matt Lentzner <***@gmail.com>
>> wrote:
>>>
>>> I've been giving this a lot of thought. Using ordinals is a disaster
>>> waiting
>>> to happen, but being able to save the values as integers has merit.
>>> Saving
>>> strings is pretty wasteful since the same string will be repeated in the
>>> database many times and you get into a potential conflict situation where
>>> readability of the enum name conflicts with not wanting to have a long
>>> string stored repetitively in the database.
>>>
>>> The nicest way to resolve the enums would be to be able to assign int
>>> values
>>> to each as opposed to getting the ordinal. If we could write the type
>>> resolver to look for a getId() call and then fall back to ordinal() this
>>> would work well. Ideally, you would want to implement the getId() method,
>>> but if you didn't you could retrofit at any time later by assigning the
>>> current ordinal values and essentially locking them in. Conceptually, the
>>> getId() dovetails nicely with foreign key behavior in the SQL database.
>>>
>>> I also attempted to override the ordinal behavior in the Enum in order to
>>> assign values, but I couldn't get it to work. I kept getting threading
>>> errors. If anyone has any advice as to where I can do the override
>>> (monkeypatch?) I'd love to hear about it. I don't think that this would
>>> have
>>> any ramifications for the proper behavior of Enum, since the ordinal
>>> values
>>> are completely arbitrary. I wouldn't be surprised if they were even
>>> required
>>> to be contiguous. Of course that needs to be tested, but I need a working
>>> implementation of that patch first.
>>>
>>> Cheers,
>>>
>>> Matt
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/are-new-Enums-in-gorm-safe--tp17699283p18513303.html
> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email