This happens for all sequencing involving JPA table generators.
This is after I have been attempting through various means to customize the session (though I haven't done anything other than call usePlatform() on the DatabaseSessionImpl class).
I am in some sort of seventh-dimension state of yak shaving such that the yak is not only bald but transdimensional and astral travelling through time.
Root problem:
The Informix database platform is buggy. It claims that Informix databases need non-ANSI OUTER JOIN syntax. Oh, no problem, I'll override this mistake.
Next problem:
We don't want to embed <property name="eclipselink.target-database" value="our.custom.InformixPlatformSubclass"/> in our persistence.xml, because Java EE configuration is so broken as to be unusable ("Hi, customer; yes, well, what you need to do is take our .ear file, unzip it, find a .jar file in there with a META-INF/persistence.xml file in it, unzip that, change the target-database property in there to whatever platform you happen to be deploying on--no, you can't rely on autodetection because the autodetected platform is broken; that's why you have to specify our custom platform--then zip up the new .jar file, and then re-zip up the .ear file containing it, and yes, we know, this violates checksums and goes against your security policies, but what can we say; it's the standard").
Next problem:
Hmm, maybe there's some EclipseLink Way to customize the session such that we can detect our own platforms, then fall back to the default mechanism. Eureka! I know, we'll write a SessionCustomizer to see if there's a Jenzabar- (my company) authored subclass of the auto-detected platform and use that if there is one. Oh, look, works like a charm! The lifecycle is right; we call setPlatformClassName() and it all works...until...oh, I see, it is nulled out and erased by the core EclipseLink machinery (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=401388) as though it never happened. Hmm, I could use that day of my life back.
Next problem:
OK, a SessionCustomizer can't customize a session's platform (don't really know why this is special, but hey, that's the way it is; can't fight it). How about a SessionListener instead, that does the same thing, but this time, reacting to...uh, a postLogin() event? Maybe then we can just call usePlatform() after all the nulling-out silliness is done. Oh, works like a charm...until this call to usePlatform() then causes all downstream inserts of any entity with a @TableGenerator to fail due to the issue reported here (i.e. the query is null in QuerySequence.java line 350 for no good reason that I can see).
Not sure how a call to usePlatform() could cause the query to be null, but there you have it.
Apologies in advance for tone; I've spent WAY too long on these series of problems over the last several days to be cool about it.
Best,
Laird
