Christian and I chatted on HipChat. It seems his confusion stems partially
from misunderstanding #createFilter, but also the fact that I did not go
into detail regarding the plans for this streaming support. I thought it
would be a good idea to discuss that at a high level here. The main thing
t
Well stop and think about it... What do you expect session.filter( new
ArrayList(), "") to do?
Yes, it has to be a PersistentCollection. Hibernate handles "persistent
arrays" as well
(see org.hibernate.collection.internal.PersistentArrayHolder), although it
is a discouraged feature.
It is used
As far as I understand from the
documentation(https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/objectstate.html#objectstate-filtering),
it can be used to filter collections and arrays. I don't know if it only
works for persistent collections but since arrays are also mentioned, I
gue
The alternative atm is to directly query against the owning entity or
directly against the element. Granted that last one assumes that the
element defines a mapped reference back to the owner to be able to apply
the restriction based on the FK, but that's the more normal mapping anyway.
So e.g.,
I knew of the request. Its just that on the EE group I am sure the
decision will be consistency.
On Mon, Jan 2, 2017 at 7:11 AM Yoann Rodiere wrote:
> > Regarding JPA adopting scrolling as a feature, what I suggest simply
> follows what Hibernate ans JPA already do for other Query returns. Tod
> Regarding JPA adopting scrolling as a feature, what I suggest simply
follows what Hibernate ans JPA already do for other Query returns. Today
it is completely inconsistent between Query#scroll and Query#list e.g.. I
am just suggesting making that consistent.
Sure. I just wanted to point out th
> I plan on removing Session#createFilter. There are numerous reasons why
which I can discuss if anyone is interested in exploring this.
I'm curious, what are the reasons for removing it? And if we remove it,
what's the alternative for people to use?
2016-12-31 21:00 GMT+01:00 Steve Ebersole :
What's the overall strategy for aligning the classic Query API with JPA for
Hibernate ORM 6? Are you e.g. going to remove uniqueResult() as it's
superseded by JPA's getSingleResult()?
If so, I also vote for changing the existing method on ScrollableResults.
Thinking about this, should there be su
org.hibernate.query.Query extends javax.persistence.TypedQuery since 5.2,
so it already has been parameterized.
Regarding JPA adopting scrolling as a feature, what I suggest simply
follows what Hibernate ans JPA already do for other Query returns. Today
it is completely inconsistent between Query
I think you are not understanding createFilter:
http://docs.jboss.org/hibernate/orm/current/javadocs/org/hibernate/Session.html#createFilter
Again, to call filter you'd have to have access to the Collection you want
to filter.
On Mon, Jan 2, 2017 at 2:40 AM Christian Beikov
wrote:
> Let's say
Let's say we have this entity with an attribute that is not directly
exposed.
class EntityA { String field; }
and then you pass a collection of EntityA instances to createFilter like
Collection collection = ...
collection = session.createFilter(collection, "field =
'abc%'").getResultList();
S
For what it's worth, changing the signature indeed seems appropriate to me:
the fewer object arrays, the better.
Your proposal would require making Query parameterized too, though. I'm not
really up-to-date with the current state of 6.0, but I guess it's already
done or being done.
Anyway, the onl
Could you explain the situation where you would map a collection but not
expose it? And btw even create createFilter would not work there because
you have to pass createFilter the collection
On Mon, Jan 2, 2017, 2:15 AM Christian Beikov
wrote:
> Well it does when you consider that there might b
Well it does when you consider that there might be no getter for a
field. With createFilter you could still filter the result list without
exposing direct access to the field via a getter.
Am 02.01.2017 um 08:52 schrieb Steve Ebersole:
> Field-access would have zero bearing on this
>
> On Mon, J
14 matches
Mail list logo