[Springframework-developer] DataFieldMaxValueIncrementer

[<jue...@we...>]

I've added PostgreSQLSequenceMaxValueIncrementer today, as attached to =
our JIRA. On the occasion, I've reviewed the incrementer =
implementations: They're too complicated for what they achieve, =
IMO.Thus, I've dropped the inner class NextMaxValueProviders and moved =
the code to the DataFieldMaxValueIncrementer class hierarchy itself.
=20
I've noticed that AbstractDataFieldMaxValueIncrementer's nextDoubleValue =
effectively returns an integer, like nextIntValue/nextLongValue - after =
all, the template method getNextKey returns a long, so there's no chance =
for a true double. Thus, I see no point in keeping the nextDoubleValue =
method in the DataFieldMaxValueIncrementer interface; all current =
implementations do not return doubles here.
=20
Furthermore, why does getNextKey take a type parameter when it returns a =
long anyway? Any JDBC driver will let you read both an int and a long =
via rs.getLong, so there's no point in that type parameter. Simply =
reading the value via getLong should be sufficient.
=20
This leaves a very simple DataFieldMaxValueIncrementer interface with =
nextIntValue, nextLongValue and nextStringValue methods, with =
implementations that achieve their goal in a straightforward fashion. =
AbstractDataFieldMaxValueIncrementer delegates all three to getNextKey =
which returns a long, casting the long to an int respectively converting =
it to a string with optional padding.
=20
This should still cover all current usages and therefore not break =
compatibility, and it should make it as easy as possible to implement an =
AbstractDataFieldMaxValueIncrementer subclass for a specific database. =
Thomas, Dmitrity, what do you think?
=20
Juergen
=20
P.S.:
Obviously, 1.0 RC2 won't be released tonight but rather at the end of =
the week. I believe it's worth it, as I'd also like to wait for feedback =
on the other recent changes.
=20