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 - 11:27:27 EDT