Ok, my excuse for being slow is a jet lag since Saturday :-)
This makes sense. I probably still would not care about this extra
level of indirection myself, but I won't have any objections if we
add "enum mapping" feature.
Andrus
On Aug 13, 2007, at 11:26 AM, Mike Kienenberger wrote:
> I think what Michael and I are trying to say is that there's both a
> database enumeration value and a java enumeration name, and we don't
> necessarily want to hardcode our database enumeration values into our
> java code when it's a part of the database model
>
> I see this as similar to mapping a database column name into a java
> method or mapping a table name to a java class.
>
> On 8/13/07, Andrus Adamchik <andru..bjectstyle.org> wrote:
>> My point was that Java 1.5 enums do address that "natively" in the
>> Java code, so mapping in the Modeler is redundant.
>>
>> Andrus
>>
>>
>> On Aug 13, 2007, at 10:54 AM, Mike Kienenberger wrote:
>>> I admit that I don't quite understand everything that's going on
>>> here
>>> since I haven't had the opportunity to use java 1.5 enumerations
>>> yet,
>>> but I can certainly see how being able to define database
>>> enumerations
>>> in the data model and then generating java constants or enumerations
>>> for them would be a useful feature.
>>>
>>> I'd make use of such a feature if it were available in the modeler.
>>> I have a large number of "*_TYPE" tables that contain data that's
>>> essentially enumerations, and under Java 1.4, I manually add
>>> constants
>>> to my non-generated DataObject classes to represent this.
>>>
>>> On 8/12/07, Andrus Adamchik <andru..bjectstyle.org> wrote:
>>>> I am reluctant to add a standard option for persisting of what
>>>> can be
>>>> considered a custom class. But I am not sure why this is even
>>>> needed?
>>>> You can code your enums as Java enums with custom properties,
>>>> and do
>>>> not use Cayenne-provided EnumExtendedType, installing your own
>>>> instead. E.g.:
>>>>
>>>>
>>>> public enum Color {
>>>>
>>>> BLACK("000000"), WHITE("FFFFFF");
>>>>
>>>> private final String dbCode;
>>>>
>>>> private Color(String dbCode) {
>>>> this.dbCode = dbCode;
>>>> }
>>>>
>>>> public String getDbCode() {
>>>> return dbCode;
>>>> }
>>>> }
>>>>
>>>> public class ColorType implements ExtendedType {
>>>>
>>>> public String getClassName() {
>>>> return Color.class.getName();
>>>> }
>>>>
>>>> public void setJdbcObject(
>>>> PreparedStatement statement,
>>>> Object value,
>>>> int pos,
>>>> int type,
>>>> int precision) throws Exception {
>>>>
>>>> if (value instanceof MyEnumType) {
>>>>
>>>> Color e = (Color) value;
>>>> statement.setString(pos, e.getDbCode());
>>>> }
>>>> else {
>>>> statement.setNull(pos, type);
>>>> }
>>>> }
>>>> ....
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Aug 9, 2007, at 1:42 PM, Michael Gentry wrote:
>>>>
>>>>> Uhm ... that's why I wanted it in the modeler and supported by
>>>>> Cayenne
>>>>> natively. (Or easier to support, even if not in the modeler.)
>>>>>
>>>>> :-)
>>>>>
>>>>> I'm positive this feature would be useful to others. My current
>>>>> approach is complicated to set up and easy to miss registering
>>>>> one of
>>>>> your types (although you blow up quickly enough) or an actual
>>>>> enumerated value (which is harder to catch). If it could be
>>>>> simplified, it could be much more useful to everyone.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> /dev/mrg
>>>>>
>>>>>
>>>>> On 8/9/07, Andrus Adamchik <andru..bjectstyle.org> wrote:
>>>>>> I see what you are saying. I guess for your case you can keep
>>>>>> using
>>>>>> custom ExtendedType (only based on JDK 1.5 enums).
>>>>>>
>>>>>> Andrus
>>>>>
>>>>
>>>>
>>>
>>
>>
>
This archive was generated by hypermail 2.0.0 : Mon Aug 13 2007 - 13:14:41 EDT