On Tue, Sep 13, 2016 at 9:55 PM Gail Badner wrote:
> Sorry for the late response. I've been looking through the fix for
> HHH-5163 [1] to jog my memory.
>
> Here are some reasons why CacheableResultTransformer is important when
> caching query results:
>
> 1) The same SQL can be generated when as
I know I started a discussion of this somewhere with some of you, but I
cannot find it anymore.
I had suggested we consider getting rid of this Query#iterate method. I
just wanted to get everyone's opinions of this. Specifically, getting of
it in 6.0.
If anyone has dug much into the current Ant
I just know of people that are using iterate() now for efficient
incremental processing, but I guess any other approach(streams maybe?)
to do incremental processing would be good enough for these users.
Unfortunately I don't know what a shallow query is or what the
implication on the query or t
Another thing we run into in 6.0 dev is handling booleans, specifically in
regards to dealing with the database representation (0 or 1, versus 'T' of
'F', versus ...).
The way we handle this today (pre-6.0) is to "fake it" by registering a
JavaTypeDescriptor for each representation combo[1]. We c
Am 27.01.2017 um 17:31 schrieb Steve Ebersole:
> Obviously that only works if there is not already an AttributeConverter
> applied to to the attribute. I cannot imagine that ever happens in a
> supported way, or a way that we want to support. Essentially that would
> mean a condition where we con
I took the flight home to play with free form and specifically how we would
retrieve data from the free form structure.
By free-form I mean non POJO but they will have schema (not expressed here).
https://github.com/emmanuelbernard/hibernate-search/commit/0bd3fbab137bdad81bfa5b9934063792a050f537
I would not bother too much about iterate since it can be easily emulated
with an entity query.
If I recall correctly, Query#iterate does something like this:
select e.id
from Entity e
where condition
and for every identifier we can load the entity from the 2nd-level cache
instead of loading it f
On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov
wrote:
> I just know of people that are using iterate() now for efficient
> incremental processing, but I guess any other approach(streams maybe?)
> to do incremental processing would be good enough for these users.
>
>
ScrollableResults do not mee
I'm sorry, I apparently confused iterate() with scroll() then, so forget
what I wrote before ^^
In face of that new info, I actually don't know of any actual users.
After thinking a bit about it, why not make that behavior configurable
via setProperty and drop that method?
Am 27.01.2017 um 19:
On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov <
christian.bei...@gmail.com> wrote:
> Am 27.01.2017 um 17:31 schrieb Steve Ebersole:
> > Obviously that only works if there is not already an AttributeConverter
> > applied to to the attribute. I cannot imagine that ever happens in a
> > supporte
Because the behavior is also fundamentally questionable.
On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
christian.bei...@gmail.com> wrote:
> I'm sorry, I apparently confused iterate() with scroll() then, so forget
> what I wrote before ^^
>
> In face of that new info, I actually don't know o
Correction : If they have not done that either, we'd simply *ask* the
Dialect.
On Fri, Jan 27, 2017 at 12:24 PM Steve Ebersole wrote:
> On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov <
> christian.bei...@gmail.com> wrote:
>
> Am 27.01.2017 um 17:31 schrieb Steve Ebersole:
> > Obviously that o
I'm for removing it even if it didn't complicate the query parser.
Vlad
On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole wrote:
> Because the behavior is also fundamentally questionable.
>
> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
> christian.bei...@gmail.com> wrote:
>
> > I'm sorry,
If you think we can handle this better using Attributes, then we can give
it a try.
Nevertheless, the current implementation is nice as well. We have a single
Java descriptor and multiple Sql descriptors to cover various DB column
types or column values.
Vlad
On Fri, Jan 27, 2017 at 8:28 PM, Ste
But see that's my point. That's *not* what we have. We have 3
JavaTypeDescriptors (instances) and 3 SqlTypeDescriptors (instances) to
handle this. Sure we have 1 JavaTypeDescriptor *class*, but it takes 3
distinct configurations. But the problem with this is... when I see a
Boolean/boolean typ
+1 to remove
On 27 January 2017 at 18:34, Vlad Mihalcea wrote:
> I'm for removing it even if it didn't complicate the query parser.
>
> Vlad
>
> On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole wrote:
>
>> Because the behavior is also fundamentally questionable.
>>
>> On Fri, Jan 27, 2017 at 12:1
+1 for remove then too. We can still add it later via a configuration
property if someone complains.
Am 27.01.2017 um 19:50 schrieb Sanne Grinovero:
> +1 to remove
>
> On 27 January 2017 at 18:34, Vlad Mihalcea wrote:
>> I'm for removing it even if it didn't complicate the query parser.
>>
>> Vl
They can always emulate it with a query that returns the ids and then just
call entityManager.find for each id so I don't think we'll ever need to add
it back.
Vlad
On Fri, Jan 27, 2017 at 9:16 PM, Christian Beikov <
christian.bei...@gmail.com> wrote:
> +1 for remove then too. We can still add i
I have a little proposal for supporting the use of a KEY expression in
the FROM clause and I'd like to hear your opinions on that.
Unfortunately the JPA spec does not support that, but since a key of a
java.util.Map mapping may be an entity type, we need to specify how one
can "join" that key ex
Fwiw EclipseLink supports both syntaxes "JOIN KEY(m) k" and also "JOIN
KEY(m).association".
Am 27.01.2017 um 20:25 schrieb Christian Beikov:
> I have a little proposal for supporting the use of a KEY expression in
> the FROM clause and I'd like to hear your opinions on that.
> Unfortunately the
My initial thoughts...
On Fri, Jan 27, 2017 at 1:29 PM Christian Beikov
wrote:
> I have a little proposal for supporting the use of a KEY expression in
> the FROM clause and I'd like to hear your opinions on that.
> Unfortunately the JPA spec does not support that, but since a key of a
> java.ut
FWIW = for what it is worth.
TBH, to me it is not worth much ;)
I don't do things "just because EclipseLink does it".
On Fri, Jan 27, 2017 at 2:33 PM Christian Beikov
wrote:
> Fwiw EclipseLink supports both syntaxes "JOIN KEY(m) k" and also "JOIN
> KEY(m).association".
>
> Am 27.01.2017 um 20
22 matches
Mail list logo
