Hi Pawel, When I saw it - but it was something years ago so memory can be wrong - it was because some database expected an operator expression and some others were not supporting "where TRUE" evaluation so "where 1=1" (similarly for <>) was a nice portable workaround.
Now I agree that criteria API is not very well defined in both the spec and openjpa and all combinations are not expected to work even if the API enables it so maybe we should also check all the related cases are valid or not from a spec point of view and ultimately from a SQL point of view. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 14 déc. 2021 à 12:51, Pawel Veselov <pawel.vese...@gmail.com> a écrit : > Hello. > > I'm trying to fix these tickets as I ran into them the other day. > -2894 looks relatively straightforward, and I have a working fix in > https://github.com/veselov/openjpa/tree/OPENJPA-2894. > > However, I ran into -2895 as I was trying to test -2894, and fixing > that looks a lot more complicated. > > Just to get -2894 to test, I've changed the TRUE/FALSE predicate > definitions from using equality and non-equality expressions to using > just constant true/false expressions. This blew out > TestTypesafeCriteria true/false tests, though the problem is just in > comparing the JPQL/CQL query text, otherwise those queries are > correct. > > So, a question: is there a (non-obvious) reason why TRUE/FALSE > Predicates should be defined as equality/non-equality, and can't be > just TRUE/FALSE boolean expressions? Once -2895 is fixed, it won't be > a problem, but still seeing (1==1) or (1<>1) instead of TRUE/FALSE > (which also optimizes out in some cases) looks more clunky to me. > > For fixing -2895, the only solution that I could find is to properly > implement toValue() for the predicates. For predicates simply wrapping > an expression, it's trivial - just return toValue() of the > expressions. But for real predicates (i.e., AND/OR/NOT operators), I > would need to build a new Value class that represents them. > > However, I'm quite overwhelmed by the requirements of the Value class. > I've tried modeling things after "Math" (similar syntax, binary > operators) and "GeneralCaseExpression" (similar structure, since > predicates can have more than two arguments), but I just don't > understand the intention of the ExpState related methods, especially > "calculateValue()" (what is this "other" value, and what's up with > reciprocity on nested values that, say, Math does), and "length" (why > does Math or GeneralCaseExpression return length of 1, what is the > definition of "element" that the corresponding JavaDoc is talking > about) > > So, two questions here: > - is there a better way for creating predicate values? Or any better > approach to solving -2895? > - if not, can somebody offer insights on the Value methods contracts? > > Thank you! > Pawel. >
