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
