Am 25.04.2018 um 00:46 schrieb Steve Ebersole:
>
>
> On Tue, Apr 24, 2018 at 5:43 PM Christian Beikov
> mailto:christian.bei...@gmail.com>> wrote:
>
> That's a possibility indeed, but there will most likely always be
> some
> nice function that uses a weird keyword syntax for which the
On Tue, Apr 24, 2018 at 5:43 PM Christian Beikov
wrote:
> That's a possibility indeed, but there will most likely always be some
> nice function that uses a weird keyword syntax for which there is no
> first class support.
>
And not only that but some databases allow extensions to the SQL spec a
That's a possibility indeed, but there will most likely always be some
nice function that uses a weird keyword syntax for which there is no
first class support.
So even if we propose this, IMO we should still also propose to add a
note to the function invocation syntax section, that a function
What I was proposing instead was to treat extract and hopefully datediff as
first-class citizens:
cb.extract( DateField.DAY, startDate ).as( Integer.class );
cb.extract( DateField.DAY, endDate - startDate ).as( Integer.class );
cb.datediff( DateField.DAY, endDate, startDate ).as( Integer.class );
I don't like this either. It simply feels wrong as this is a "provider
specific" keyword i.e. some DBMS might not even support DATEDIFF. IMO
when we decide to abstract over the DBMS specifics by introducing a HQL
DATEDIFF or specifying a JPQL DATEDIFF, we could just as well introduce
separate f
Yep, it was clear
On Tue, Apr 24, 2018 at 4:57 PM Gail Badner wrote:
> I just want to make sure that what I'm suggesting is clear.
>
> datediff would be registered as a function:
>
> registerFunction( "datediff",
>new StandardSQLFunction( "datediff", StandardBasicTypes.INTEGER )
> );
>
> The
I just want to make sure that what I'm suggesting is clear.
datediff would be registered as a function:
registerFunction( "datediff",
new StandardSQLFunction( "datediff", StandardBasicTypes.INTEGER )
);
Then, to specify datediff with the keyword, day, as the first parameter
(rendered without
I'd personally not like that approach. I think specific registrations (for
extract and datediff) are better options
On Tue, Apr 24, 2018, 1:18 PM Gail Badner wrote:
> When I asked about whether JPA should support this in the future, I was
> thinking along the lines of adding something like the
When I asked about whether JPA should support this in the future, I was
thinking along the lines of adding something like the following
to javax.persistence.criteria.CriteriaBuilder:
Keyword keyword(String value); // rendered as a String without quotes
or:
Expression literal(String value, enclo
Maybe we should wait until it transitioned to Eclipse then? Or do you
think it might make sense to start discussions already?
The API could be String based by default but allow to "unwrap" to do
something provider specific. If the providers model requires it, the
String could be parsed by the p
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 mechanis
On Tue, Apr 24, 2018 at 8:45 AM Gail Badner 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
I'm speaking about a mechanism to define what Hibernate calls
`SQLFunction` in a JPA standard way. Every JPA provider has this
concept. I even implemented a JPA provider abstraction for this in
Blaze-Persistence and it works pretty well.
How does the specification process in the Eclipse Foundat
Section 4.6.17.3 unfortunately also very strictly limits the sources of
values for the arguments that can be passed to the functions using its
`function(name, ...)` syntax. And unfortunately SQL keywords is not one of
those.
On Tue, Apr 24, 2018 at 9:12 AM Steve Ebersole wrote:
> When you say "
When you say "standardize the definition of functions", are you speaking
about the which functions are defined as "built-in functions" or a
mechanism in JPA to define `SQLFunction` overrides/extras?
JPA already has quite a number of built-in functions defined: MIN, TRIM,
LOWER, etc. I think we'd
Hi,
Here are the minutes of the latest NoORM IRC meeting:
(15:40:17) jbott: Meeting ended Tue Apr 24 13:39:22 2018 UTC. Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
(15:40:17) jbott: Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibe
The JPA spec actually says the function invocation syntax can be used
for database functions in 4.6.17.3.
By "supported" you mean something like a note that says JPA providers
may allow the invocation of JPA provider specific functions via that
syntax? I'd love to go even further and standardiz
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?
On Mon, Apr 23, 2018 at 11:45 PM, Christian Beikov <
christian.bei...@gmail.com> wrote:
> Hey Gail,
>
> I usually register a de
18 matches
Mail list logo
