JPA is technically under the old JCP still AFAIK. So for now the process would be the same it has always been.
I just do not see how this would ever get agreed upon for a standardized contract - it is so very dependent upon how the provider models the query (SQM e.g.) versus the specific mechanism they use to render it (SQL AST). On Tue, Apr 24, 2018 at 9:29 AM Steve Ebersole <st...@hibernate.org> wrote: > On Tue, Apr 24, 2018 at 8:45 AM Gail Badner <gbad...@redhat.com> wrote: > >> Yes, that should work with CriteriaQuery as well. It's a reasonable >> workaround. >> >> If JPA doesn't support this now, is it something that should be supported >> in the future? > > > The problem with defining support for this in the spec is that it is > relying on Hibernate's "SQL function registry" and its `SQLFunction` > contract. I seriously doubt we'd get all the EG members to agree to some > standardization of anything like a `SQLFunction` contract. > > I think proposing to add additional functions to the spec as "built-in" is > probably more likely. I can especially see EXTRACT being likely. Maybe > DATEDIFF. Oracle for sure does not support DATEDIFF, but it does support > the EXTRACT-from-INTERVAL approach. Anyone know offhand other databases > which to not define DATEIDFF? > > I personally think having DATEDIFF defined as "built-in" is the best > option as the provider can always map that to EXTRACT-from-INTERVAL for > Oracle, etal - its much harder to do that by mapping EXTRACT-from-INTERVAL > to DATEDIFF. > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
