On 28-7-2016 18:07, Steve Ebersole wrote:
I do think this is an error. I think the proper fix is to first
make use of Exporter<Sequence>#getSqlCreateStrings via
Dialect#getSequenceExporter.
From there, either:
1. Change the standard Exporter<Sequence> to look at
Dialect#supportsPooledSequences and deciding which
Dialect#getCreateSequenceStrings form to call
2. Change Firebird's Exporter<Sequence> impl
I have fixed the immediate problem by implementing the
getCreateSequenceStrings(String, int, int) and
getCreateSequenceString(String, int, int) as:
@Override
public String[] getCreateSequenceStrings(String sequenceName, int
initialValue, int incrementSize) throws MappingException {
return new String[] {
getCreateSequenceString( sequenceName, initialValue,
incrementSize ),
"alter sequence " + sequenceName + " restart with " +
(initialValue - 1)
};
}
@Override
protected String getCreateSequenceString(String sequenceName, int
initialValue, int incrementSize)
throws MappingException {
if (incrementSize > 1) {
throw new MappingException( getClass().getName() + " does not
support pooled sequences" );
}
// Ignore initialValue and incrementSize
return getCreateSequenceString( sequenceName );
}
So as long as a non-pooled sequence (incrementSize = 1) is requested the
Firebird25Dialect will happily oblige. I will add a similar solution to
the InterbaseDialect and FirebirdDialect.
I'd also suggest we properly deprecate
Dialect#supportsPooledSequences,
Dialect#getCreateSequenceStrings directing to Dialect#getSequenceExporter.
The problem with that is that the StandardSequenceExporter uses
getCreateSequenceStrings to do its work, so deprecating that would
require more rework.
Mark
--
Mark Rotteveel