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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
