So during parsing you try to lookup the castTarget and if it can't be
found, just pass through? If you pass it through, what would be the type
of the expression?
I'd like to present an idea I just had. How about we reuse the "TREAT"
function/operator for doing these "casts" to named types. Appl
Looks good. OTOH I'd also like to see the following functions
* millisecond_diff
* second_diff
* minute_diff
* hour_diff
* day_diff
* week_diff
* month_diff
* quater_diff
* year_diff
* epoch - generally defined as `extract(epoch from ?1)`
* group_concat - string aggregation f
You mean something like `treat( cast(x as some_db_type) as String)`?
On Wed, May 31, 2017 at 1:12 AM Christian Beikov
wrote:
> So during parsing you try to lookup the castTarget and if it can't be
> found, just pass through? If you pass it through, what would be the type of
> the expression?
>
Oh, I just saw your last statement. I'm not a fan of "only ever [using
cast function] for the pass-through case"
On Wed, May 31, 2017 at 6:43 AM Steve Ebersole wrote:
> You mean something like `treat( cast(x as some_db_type) as String)`?
>
>
> On Wed, May 31, 2017 at 1:12 AM Christian Beikov <
Ok, as there are no objections to switching `str` from CHAR to VARCHAR cast
I will make that change.
On Tue, May 30, 2017 at 8:09 AM Sanne Grinovero wrote:
> On 30 May 2017 at 13:02, Steve Ebersole wrote:
> > For whatever reason JPA and a few of the databases do not categorize
> > coalesce and
Yeah the example you gave would reflect what I was thinking about.
How would you determine the expression type if the castTarget is just
"passed-through" then?
Mit freundlichen Grüßen,
*Christian Beikov*
Am 31.05.2017 um 1
Thanks for reply Christian..
On Wed, May 31, 2017 at 7:18 AM Christian Beikov
wrote:
> Looks good. OTOH I'd also like to see the following functions
>
> * millisecond_diff
> * second_diff
> * minute_diff
> * hour_diff
> * day_diff
> * week_diff
> * month_diff
> * quater_diff
>
We would not be able to. That is the trouble with any kind of
"pass-through. We would need some form of hint/directive from the user.
Also in thinking about it some more, I think that re-using treat is not
appropriate. treat is specifically defined in regards to hierarchies,
which mean this use
Answers inline...
Am 31.05.2017 um 14:38 schrieb Steve Ebersole:
> Thanks for reply Christian..
>
>
> On Wed, May 31, 2017 at 7:18 AM Christian Beikov
> mailto:christian.bei...@gmail.com>> wrote:
>
> Looks good. OTOH I'd also like to see the following functions
>
> * millisecond_diff
>
The naming problem and because people might be used to specify "managed
type names" with "treat" is actually why I suggested to reuse "treat".
I don't know how you'd like to implement the cast function, but allowing
to mix the type names/codes with actual DBMS specific type names doesn't
sound
So you see how this is getting WAAY to compicated? I'd prefer to keep
this simple. People know what to expect of `cast`. I am trying to make
this as broadly applicable as *reasonably* possible, but if this is going
to "be a thing" then I say we limit this to just Java types.
On Wed, May 31
Hi all,
we released three versions of Hibernate Search, backporting various
bugfixes to all maintained branches.
Please see the blog for more details:
- http://in.relation.to/2017/05/31/HibernateSearchMaintenanceReleases/
Thanks,
Sanne
___
hibernate-d
12 matches
Mail list logo
