Hi,
since the ordering of the enum is now correct (thank you very much :) I now
encounter another "problem" , but this is not a bug....
One thing I like about enums is that you can add code. One can implement a
lifecycle, for instance, with a state transition matrix,
and has little trouble implementing that with an enum.
For instance:
public enum ApplicationLifeCycle {
/* states. */
NOT_INITIALIZED, INITIALIZED, BOOTING, BOOTING_ABORTED, BOOTING_FAILED,
RUNNING, SLEEPING, CLEANUP_IN_PROGRESS, SHUTDOWN_IN_PROGRESS,
SHUTDOWN_DONE, SHUTDOWN_FAILED, CLOSED;
/** holds the state transition matrix. */
private static final boolean[][] statematrix =
new
boolean[ApplicationLifeCycle.values().length][ApplicationLifeCycle.values().length];
/** initializes the possible transitions. */
static {
/* going into the init state. */
statematrix[NOT_INITIALIZED.ordinal()][INITIALIZED.ordinal()] = true;
/* booting all dependencies, services etc. */
statematrix[INITIALIZED.ordinal()][BOOTING.ordinal()] = true;
statematrix[BOOTING.ordinal()][BOOTING_FAILED.ordinal()] = true;
statematrix[BOOTING.ordinal()][BOOTING_ABORTED.ordinal()] = true;
.....
}
/**
* Checks whether the state can change to the given state.
* @param state to check whether it is reachable.
* @return whether it is.
*/
public boolean canChange(ApplicationLifeCycle state) {
rejectNotInitialized(state);
return statematrix[this.ordinal()][state.ordinal()];
}
/**
* The builder(caller) assumes that it is in a lifecycle state that can can
make a transition to the given state.
* @param state which the builder wants to make a transition to.
*/
public void expectCanChangeTo(ApplicationLifeCycle state) {
if (!canChange(state)) {
throw new IllegalStateException(CAN_T_CHANGE_STATE + this.name() + ARROW +
state.name());
}
}
}
My point is, that enums are very versatile, MINUS you CAN'T INHERIT, only
implement.
It would be great if the enums I define in the database server could be
"enhanced" with code.
Means: if jOOQ could use a "enum skeleton" to render generated code, one
could easily add a lot of functionality
and logic based on the enum values in the database.
Or, apply some fixing. For instance the Calendar.DAYS_ENUM_VALUES in Java
start with #1, and the
enums ordinal starts (correctly) with #0. If one could supply a skeleton
enum with mapper function, one
could fix some issues with numbering and other inconsistencies in the
database.
But as I pointed out above with the lifecycle, there could be other
applications too.
>From my point of view, there should be a configuration option that
specifies a skeleton for a specific class.
A skeleton enum/class file must then contain code, but NOT the enum values
definition, which will be generated by JOOQ.
I have read the documentation concerning the enum converters.
http://www.jooq.org/doc/3.1/manual/sql-execution/fetching/data-type-conversion/
But I think this feature is different.
What do you think about it?
Best,
Patrik
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
