We can propose it. Personally I do not think that section explicitly
precludes what we do, but I agree that it does imply the function
invocation should be "passed through". I think this might be difficult to
get consensus on though - just a quick look at EclipseLink and TopLink show
that they de
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
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
Hey Gail,
I usually register a dedicated SQLFunction for every time value in the
Dialect and use these functions instead. So in your case, I'd have a
"day" function and use it like
final Expression diff = cb.function("DAY", Integer.class, ...
).as(Integer.class);
The fuction will then render
SQL Server defines a function:
DATEDIFF ( datepart , startdate , enddate ) [1]
(This method still needs to be added to SQLServer2012Dialect.)
datepart can be one of a variety of time values, e.g., day, week, year, etc.
On SQL Server (at least) the value for datepart cannot be treated as a
lite
20 matches
Mail list logo
