I agree that the migration guide should mention that{{AbstractPostInsertGenerator}} was removed. In fact, I’m not even clear why I decided to actually remove this class rather than leaving:
@Deprecated
public abstract class AbstractPostInsertGenerator
implements PostInsertIdentifierGenerator, BulkInsertionCapableIdentifierGenerator {}
In fact, I’m not against putting a stub like this back, for the purpose of backward compatibility. That said, I’m not sure I understand any of the other objections in this issue report, nor do I understand where the alleged “bug” might be located.
- A PostInsertIdentifierGenerator should never be doing things in generate(), since that method is called before the insert. The contract prior to 6.3 used to be that a PostInsertIdentifierGenerator was supposed to just return the dummy value POST_INSERT_INDICATOR from that method. Now, with the new, much improved design, a PostInsertIdentifierGenerator doesn’t have that method at all. So the displayed code example simply doesn’t seem to make much sense to my eyes.
- It’s simply not correct that IdentityGenerator is missing the methods it used to inherit from AbstractPostInsertGenerator. All that has happened is that those methods have become default methods of the super-interfaces, completely obviating the need for AbstractPostInsertGenerator.
So the migration path from AbstractPostInsertGenerator is simply to inherit BulkInsertionCapableIdentifierGenerator and PostInsertIdentifierGenerator directly. We could either method that in the migration guide, or put back the stub implementation of AbstractPostInsertGenerator that I show above. (I don’t care which.) |