Version 19
Created by sebersole on Jul 19, 2009 5:58 PM. Last modified by sebersole on Sep 17, 2009 5:03 PM.
    1. Criteria Queries
      1. javax.persistence.criteria.CriteriaQuery : getSelection() returns a Selection<T> however select(Selection<? extends T>).  Why not  Selection<? extends T> getSelection()?
      2. javax.persistence.criteria.Order - Both factory methods for creating an Order take Expression<?>, but Order.getExpression() is  expected to return <T extends Comparable<T>> Expression<T>.  In the latest post-PFD version, Order#getExpression() has been updated to return Expression<?>
      3. javax.persistence.criteria.Predicate extends javax.persistence.criteria.Selection (by way of javax.persistence.criteria.Expression<Boolean>).  While technically the
        ANSI SQL spec does allow selection of boolean values, I cannot think of a major database which actually supports this.  Considering, should this really be allowed?         The decision was that the API should not disallow anything alowed in ANSI SQL just because most/all databases do not support it.
      4. Both javax.persistence.Parameter and javax.persistence.criteria.ParameterExpression  are expected to report their position when positional, but that position cannot be know until *much* later (really not until  after the query is "compiled").  Parameters are never positional in criteria queries; parameters are expected to be used in a very different way in criteria queries: basically the user holds on to the ParameterExpression instances and uses them to set values later on (or (re)obtains them from CriteriaQuery#getParameters)
      5. QueryBuilder defines isTrue(Expression<Boolean>) and isFalse(Expression<Boolean>).  Just want to check whether this is intended to be a check of a Java boolean value, or a SQL explicit truth value check (a>b is true).  The fact that the parameter is an  Expression<Boolean> and therefore probably a Predicate I am assuming the later.  But again wanted to double check.  And for  curiosity, if the later, why not complete it and allow for IS UNKNOWN checks too? These methods are meant to explictly convert the Expression<Boolean> arguments into Predicates; usually this will just be a cast.
      6. Froms (javax.persistence.criteria.From) define both joins and fetches.  Are fetches implicitly to be returned in getJoins()?  So if I add a fetch, should its underlying join be returned from getJoins()?
      7. The COALESCE, CASE and IN builders all have an issue with not being able to know the javatype up front (or possibly ever).  We need to get clarification on the intent there.
      8. nullif(Expression<Y> exp1, Expression<?> exp2) and nullif(Expression<Y> exp1, Y exp2)... Why the difference in types for exp2?
      9. QueryBuilder$SimpleCase#otherwise returns Expression<R>.  Which Expression<R>?  The case expression (which is Expression<R> as well)?  The the expression used in the otherwise?
      10. Same as #9 for QueryBuilder$Case#otherwise...
      11. what QueryBuilder calls quotient...
        1. is that supposed to be normal division or integer division?  Because the return is Expression<Number> instead of Expression<Integer> I have to assume the purpose is regular division, the confusion being that quotient is normally used in reference to integer division.  The working assumption will be that this should produce a regual division...
        2. Why is the return type here Expression<Number> while all the rest of the arithmetic expressions are <N extends Number> Expression<N> ?
      12. CriteriaQuery#getParameters() : Do parameters from subqueries "report up"?  Or are we expecting users to go to each subquery and call getParameters() to determine the full set of parameters.  If the former, its ok then that the parameters from subqueries would be reported in both?  The working assumption is that CriteriaQuery#getParameters() returns the aggregation of all parameters "under it" including those from subqueries.  They should be aggregated.  Not sure where I thought I saw Subquery#getParameters, but it does not exist.
      13. MapJoin#entry() requires returning an Expression<Map.Entry<K,V>>.  Yet I do not see any possibility of getting a reference to the Class<Map.Entry<K,V>> for the corresponding Expression#getJavaType.  I know we could just use the raw type (Map.Entry.class), but want to investigate other options.
      14. Subquery & correlations : how are the correlation predicates/restrictions defined?  All the correlate methods simply take some form of javax.persistence.criteria.From  Ok I got it now (thanks Gavin).  This allows defining a Subquery from as a path join expression from the outer query.  In HQL/JPAQL term think "... from Customer c join c.orders as o where (select count(*) from o.lineItems li where li.product.productLine = :someProductLine" ) > 2"; specifically the "from o.lineItems" part.  'o' repesetns the stuff passed in to these correlate() methods...
      15. Subquery#getJoins() : what is the intent here?   The docs say "Return the joins that have been made from the subquery.", but that's misleading.  To me, joins made "from the subquery" implies that the subquery is used as a derived table declaration (in the from clause) which then acts as the left-hand side of a join.  However, that syntax is not supported by JPAQL.  Which left 2 potential interpretations of whcih I could think
        1. collect joins from the javax.persistence.criteria.From instances making up the subquery abstract schema spaces, but those are already handled by getJoins() on the Subquery's getRoots().
        2. collect the joins related to the correlations.  These would be joins that are rooted with a table in the outer query, where the actual join is scoped to the inner query.  The implication being that the results from the various #correlate methods are
          1. different then the input
          2. represent the "abstract schema" references given, but scoped to the subquery so that joins can be handled in this manner.
          Subquery#getJoins() has been renamed to Subquery#getCorrelatedJoins, and the intent with these is what is outlined in 15.2