ORM 5.2.x: Deprecation of some Query methods?
by Sanne Grinovero
Some methods from org.hibernate.Query<R> like
- org.hibernate.Query.scroll()
- org.hibernate.Query.iterate()
are now flagged as "deprecated method usage" in the IDE as they are
defined on the deprecated interface `org.hibernate.Query`, which is
being replaced by `org.hibernate.query.Query<R>`.
The new interface extends the old one, I guess for drop-in
compatibility reasons, however it doesn't explicitly re-define such
methods making me unsure about their destiny.
Are these really meant to be deprecated?
Thanks,
Sanne
8 years, 4 months
MultiCollectionOwnerIdentifierLoadAccess?
by Steve Ebersole
I'm curious if anyone sees value in
a MultiCollectionOwnerIdentifierLoadAccess variant (or some more concise
name) of MultiIdentifierLoadAccess for bulk initializing a collection role
based on their owner ids?
8 years, 4 months
Unbound type parameters and JPA metamodel
by Steve Ebersole
We are having an interesting discussion on
https://github.com/hibernate/hibernate-orm/pull/1723 in regards to
${subject}
I do think this is something we need to clarify within the EG. One thing
I'd like to do is to have a public poll to see how people tend to view
this. The main reason being that I'd like to have a public opinion as
opposed to simply following vendor-X's solution "just because". That's
easier if we can show public tendency.
I'll write up a blog post explaining the situation and then I'd like to see
us blast this out via twitter, G+, etc to get people to respond.
8 years, 4 months
Re: [hibernate-dev] [OGM] Keeping the order of the collection of elements in MongoDB
by Sanne Grinovero
On 13 January 2017 at 15:30, Yoann Rodiere <yrodiere(a)redhat.com> wrote:
> Hi Sanne,
>
>>
>> while you might be using a specific implementation when persisting
>> your new entities, when you're loading the object back from the
>> database how is Hibernate supposed to know
>> A) which implementation you want it to use
>
> Ok, that's true for most collection interfaces, but I'm not sure I
> understand why what Hibernate can guess is relevant here. Users are free to
> use custom collection types, at least in ORM. Is it not the case with OGM?
> Will it never be possible?
Sure, OGM should (eventually?) be able to do the same as ORM.
But in this case we're not talking about the case in which you use a
custom collection; my question is if you map a "Collection" with
nothing else than a - for example - @OneToMany annotation, when you
load it Hibernate core (OGM and/or ORM) will not use the same
collection implementation which you used when you stored the object.
>
> I thought we were talking about making the collection persister
> persist/retrieve the elements in the same order as they were retrieved from
> the collection. If it's not the case, then yes, I'm missing something.
>
> However, even in the specific case of Collection, by default Hibernate
> instantiates a List behind the scene for such properties (well, a
> PersistentBag, but it's basically a List). Thus if the original collection
> had some kind of "ordering memory", at least this would be preserved,
> provided we persist elements in the same order we retrieved them from the
> original collection.
>
>> B) which order to use, if you didn't map e.g. an order column to
>> store the ordering information (MongoDB not needing a strategy is an
>> exception)
>
>
> Well, we don't want to frustrate OGM users with limitations from the
> relational world, do we? Wouldn't other document datastores also allow to
> persist the elements' order?
But why wouldn't you use a List if you need a list?
>
>> A List expresses the ordering requirement by contract; if you map a
>> relation as "Collection" I wage you're not interested in the order,
>> but you're rather more interested in accepting a wide range of
>> implementations, some of which might ignore the ordering requirement.
>> By doing so, you're explicitly telling both ORM and your other code
>> interacting with the model that ignoring the order is acceptable.
>> BTW I suspect mapping things as a generic Collection is a very unusual
>> (or lazy) choice; I don't remember ever using it as it's quite
>> ambiguous, and there's no way any specification diagram will lead you
>> to recommend using a Collection (other than cleanly and explicitly
>> wanting to express you don't care about ordering, nor other properties
>> like uniqueness...)
>
>
> By exposing a Collection, you're not telling the order isn't important, and
> certainly not that it can change for no reason (which is our concern here).
> In fact, you're not telling anything about the order.
> By exposing a List, you're telling more than just "the order is important".
> What you're telling is "the order can be managed explicitly by an external
> actor". Also, you're telling "random access is possible" (not necessarily
> efficient, but possible).
>
> So while I probably wouldn't bother myself, I can see why someone would
> choose Collection over List: to avoid unnecessarily exposing promises to
> users.
I'm a bit lost here. If you don't want to expose an "unnecessary
promise" like ordering, why would you need OGM to maintain ordering?
Keeping such ordering might come at a non-trivial cost; sometimes just
computation wise, sometimes on query complexity and/or space when the
order column needs to be stored. It just happens to be cheap and -
apparently - "natural" on MongoDB.
BTW I'm not even 100% convinced about my previous suggestion about
supporting this, as maybe it would set a bad precedent?
The risk is that after developing on OGM/MongoDB you start expecting
this to work fine on other systems, so from this perspective our API
would not have a clear contract on the expectations one should have.
> You could add documentation on a getter stating what the expected ordering
> is (and, frankly, it may be relevant even with a List: how would you
> translate "the invoices are ordered by issuing date" in terms of a Java
> interface?). But what you cannot (or at least, shouldn't) do is
> contradicting the interfaces you expose ("yeah, I'm exposing a List because
> elements are ordered explicitly since we only ever add one at the end, but
> please be nice and don't try random access, it's a very long linked list").
> And no, I don't consider that "instanceof RandomAccess" on the client side
> would be a clean solution...
>
> I'm not saying "it's super important, a critical use case, we can't ship a
> new release without this, let's spend 3 months working on it". I'm just
> saying it may be relevant for other collection types, so if we do it for
> lists, and if it's not much more difficult to do it for other collection
> types, why wouldn't we?
ah, maybe I understand now. If you're proposing we do a similar thing
for other specific collection types then sure we can discuss that. I
had the impression you wanted to store ordering for properties
literally using the *Collection* signature.
>
>
> Yoann Rodière <yrodiere(a)redhat.com>
> Software Engineer
> Red Hat / Hibernate NoORM Team
>
> On 13 January 2017 at 15:26, Sanne Grinovero <sanne(a)hibernate.org> wrote:
>>
>> Hi Yoann,
>>
>> while you might be using a specific implementation when persisting
>> your new entities, when you're loading the object back from the
>> database how is Hibernate supposed to know
>> A) which implementation you want it to use
>> B) which order to use, if you didn't map e.g. an order column to
>> store the ordering information (MongoDB not needing a strategy is an
>> exception)
>>
>> The entity model expresses the intent of the end user, but also it
>> expresses its requirements which will be taken into account by ORM
>> when it needs to provide an implementation for the "Collection"
>> interface.
>>
>> A List expresses the ordering requirement by contract; if you map a
>> relation as "Collection" I wage you're not interested in the order,
>> but you're rather more interested in accepting a wide range of
>> implementations, some of which might ignore the ordering requirement.
>> By doing so, you're explicitly telling both ORM and your other code
>> interacting with the model that ignoring the order is acceptable.
>>
>> BTW I suspect mapping things as a generic Collection is a very unusual
>> (or lazy) choice; I don't remember ever using it as it's quite
>> ambiguous, and there's no way any specification diagram will lead you
>> to recommend using a Collection (other than cleanly and explicitly
>> wanting to express you don't care about ordering, nor other properties
>> like uniqueness...)
>>
>> Thanks,
>> Sanne
>>
>>
>> On 13 January 2017 at 13:29, Yoann Rodiere <yrodiere(a)redhat.com> wrote:
>> >> I think it's a reasonable expectation, as long as we're talking
>> >> specifically about mapping a *List* and not just a generic Collection.
>> >
>> >
>> > Ah, this topic again :) I know I'll be all lone, but I'll try anyway!
>> >
>> > If we do it for List, and unless there are technical issues that prevent
>> > us
>> > from doing so, I would be in favor of doing it for any kind of
>> > collection.
>> >
>> > In Collections, the fact that iteration order is deterministic is mostly
>> > up
>> > to the implementation, which is different from saying it's not
>> > deterministic. From the javadoc for Collection#iterator():
>> >
>> >> There are no guarantees concerning the order in which the elements are
>> >> returned
>> >> (unless this collection is an instance of some class that provides a
>> >> guarantee).
>> >
>> >
>> > Deterministic, and even predictable order is not exclusive to List,
>> > either:
>> > for instance, LinkedHashSet is not a List, it has a specific iteration
>> > order, but there is nothing in its implemented interfaces (Collection,
>> > Set)
>> > that defines this order.
>> >
>> > My point is, we can't rely on the implemented interface to decide
>> > whether
>> > the iteration order is important or not, so we may as well decide it is
>> > always important. Unless there are annoying technical challenges, of
>> > course.
>> >
>> > Yoann Rodière <yrodiere(a)redhat.com>
>> > Software Engineer
>> > Red Hat / Hibernate NoORM Team
>> >
>> > On 13 January 2017 at 13:48, Sanne Grinovero <sanne(a)hibernate.org>
>> > wrote:
>> >>
>> >> I think it's a reasonable expectation, as long as we're talking
>> >> specifically about mapping a *List* and not just a generic Collection.
>> >>
>> >> On 13 January 2017 at 12:18, Davide D'Alto <davide(a)hibernate.org>
>> >> wrote:
>> >> > Hi,
>> >> > it seems that when using Collection of elements in MongoDB, users
>> >> > expect to have the elements in the same order as in the db. You can
>> >> > see the question on the forum here:
>> >> >
>> >> >
>> >> > https://forum.hibernate.org/viewtopic.php?f=31&t=1043903&p=2491218#p2491218
>> >> >
>> >> > I also found this StackOverflow question:
>> >> >
>> >> >
>> >> > http://stackoverflow.com/questions/9013916/do-arrays-stored-in-mongodb-ke...
>> >> >
>> >> > What do you think? Is it something that we should support?
>> >> >
>> >> > Cheers,
>> >> > Davide
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev(a)lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev(a)lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>
>
8 years, 4 months
Re: [hibernate-dev] [OGM] Keeping the order of the collection of elements in MongoDB
by Sanne Grinovero
Hi Yoann,
while you might be using a specific implementation when persisting
your new entities, when you're loading the object back from the
database how is Hibernate supposed to know
A) which implementation you want it to use
B) which order to use, if you didn't map e.g. an order column to
store the ordering information (MongoDB not needing a strategy is an
exception)
The entity model expresses the intent of the end user, but also it
expresses its requirements which will be taken into account by ORM
when it needs to provide an implementation for the "Collection"
interface.
A List expresses the ordering requirement by contract; if you map a
relation as "Collection" I wage you're not interested in the order,
but you're rather more interested in accepting a wide range of
implementations, some of which might ignore the ordering requirement.
By doing so, you're explicitly telling both ORM and your other code
interacting with the model that ignoring the order is acceptable.
BTW I suspect mapping things as a generic Collection is a very unusual
(or lazy) choice; I don't remember ever using it as it's quite
ambiguous, and there's no way any specification diagram will lead you
to recommend using a Collection (other than cleanly and explicitly
wanting to express you don't care about ordering, nor other properties
like uniqueness...)
Thanks,
Sanne
On 13 January 2017 at 13:29, Yoann Rodiere <yrodiere(a)redhat.com> wrote:
>> I think it's a reasonable expectation, as long as we're talking
>> specifically about mapping a *List* and not just a generic Collection.
>
>
> Ah, this topic again :) I know I'll be all lone, but I'll try anyway!
>
> If we do it for List, and unless there are technical issues that prevent us
> from doing so, I would be in favor of doing it for any kind of collection.
>
> In Collections, the fact that iteration order is deterministic is mostly up
> to the implementation, which is different from saying it's not
> deterministic. From the javadoc for Collection#iterator():
>
>> There are no guarantees concerning the order in which the elements are
>> returned
>> (unless this collection is an instance of some class that provides a
>> guarantee).
>
>
> Deterministic, and even predictable order is not exclusive to List, either:
> for instance, LinkedHashSet is not a List, it has a specific iteration
> order, but there is nothing in its implemented interfaces (Collection, Set)
> that defines this order.
>
> My point is, we can't rely on the implemented interface to decide whether
> the iteration order is important or not, so we may as well decide it is
> always important. Unless there are annoying technical challenges, of course.
>
> Yoann Rodière <yrodiere(a)redhat.com>
> Software Engineer
> Red Hat / Hibernate NoORM Team
>
> On 13 January 2017 at 13:48, Sanne Grinovero <sanne(a)hibernate.org> wrote:
>>
>> I think it's a reasonable expectation, as long as we're talking
>> specifically about mapping a *List* and not just a generic Collection.
>>
>> On 13 January 2017 at 12:18, Davide D'Alto <davide(a)hibernate.org> wrote:
>> > Hi,
>> > it seems that when using Collection of elements in MongoDB, users
>> > expect to have the elements in the same order as in the db. You can
>> > see the question on the forum here:
>> >
>> > https://forum.hibernate.org/viewtopic.php?f=31&t=1043903&p=2491218#p2491218
>> >
>> > I also found this StackOverflow question:
>> >
>> > http://stackoverflow.com/questions/9013916/do-arrays-stored-in-mongodb-ke...
>> >
>> > What do you think? Is it something that we should support?
>> >
>> > Cheers,
>> > Davide
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
8 years, 4 months
Javassist enhancement problems with the Hibernate ORM WildFly modules
by Sanne Grinovero
Hi all,
I'm finding several issues around this subject. While I tried several
workarounds, I'd like us to agree on a strategy to address the root
problem which is that Hibernate ORM might not necessarily want to use
the Javassist version provided by WildFly, yet this is currently being
forced on us.
#Manifestation
The problem manifests itself as a ClassCastException on casting the
enhanced entity to a Javassist Proxy: it has been enhanced by a
different Javassist instance than the one being used by ORM during
runtime.
#Need more tests
First of, let me clarify that these issues are highlighted only the
Hibernate Search testsuite, as we're trying to use these modules.
Apparently the two tests we have in ORM to cover for the modules were
not enough to highlight this problem.. we'll need to expand them.
#The problem: duplicate dependency
The WildFly modules include the Javassist version which ORM is using
during the build, but also depends on the one provided by WildFly:
- https://github.com/hibernate/hibernate-orm/blob/master/hibernate-orm-modu...
[There seems to be a comment about this but I guess we forgot to
actually comment out the next line]
#Which one?
So I tried to comment out the reference to the WildFly module, but
that gets me in more trouble as the JipiJapa integration will (my
guess) use the "WildFly edition" of Javassist.
Doing the opposite actually seems to work fine, but I guess there are
reasons for ORM to have upgraded Javassist?
#Failed workarounds
I tried to disable class enhancement by setting either (and both!) of:
- jboss.as.jpa.classtransformer = false
- hibernate.ejb.use_class_enhancer = false
I found these on the WildFly JPA Wiki [1], but it looks like they are
not effective?
#Viable workaround
Removing the new Javassist version from the ORM module fixed my
problems, but I'm not comfortable with this unless someone could
confirm the version upgrade can wait, at least for the purpose of what
we package in these modules?
#Better fix
I suspect the better solution would be for ORM to fully re-package the
JipiJapa integration, so that we're able to be in control of version
upgrade needs without having to wait for WildFly release cycles and
other planets to align.
#Wishlist: Modules refactoring
Another reason for which I'd like ORM to "own" these modules, is that
we could evolve them better. For example:
- it seems the JipiJapa integration is having loads of dependencies
which I suspect it doesn't really need.
- we should hide Javassist & Byte Buddy from being exposed to the application
- make Byte Buddy an option: I guess improve the JipiJapa itegration
to support it and move it into its own private module.
## Suggestions?
I'm stuck again on Hibernate Search upgrading to latest ORM so I'll
see to apply the workaround without waiting for the proper solution.
Not sure which actions I should take on ORM?
Personally I think I'd just patch the modules to use the older
Javassist when running on WildFly; that upgrade should wait for either
WildFly to upgrade, or use to rethink these modules.
Scott, could you help me by verifying if and were I should open a JIRA
for those properties being ignored?
Thanks,
Sanne
1 - https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPARefer...
8 years, 4 months
[SEARCH] Remove support for (or deprecate) date/calendar resolution?
by Yoann Rodiere
Hi,
That's a catchy subject, now I'm sure I got Guillaume's (angry) attention :)
Sanne wanted us to think about feature removal... Here's a proposal.
The feature I'd like to deprecate/remove: automatic truncation of
date/calendars to a given resolution. It's used like that:
@Field
@CalendarBridge(resolution = Resolution.DAY)
private Calendar dateSent;
I've been working on date-related tests for the past few hours (well,
months, too), and I'm becoming more and more convinced that this resolution
thing is the wrong solution to an admittedly common issue. The other (in my
opinion right) solution being to use range queries.
When we truncate a date to a given resolution, we must use a particular
timezone, obviously. It makes no sense to truncate to the day when we don't
choose a particular timezone.
Then the truncated date will match only if we search for dates whose
truncation is identical in this timezone.
And guess what? In the current implementation, we use... GMT. Always. See
how org.apache.lucene.document.DateTools.round(long, Resolution) works,
getting the calendar used for truncation from TL_CAL, which uses the GMT
timezone.
What it means is that the truncation currently produces rather unexpected
results as soon as applications use a timezone different from GMT.
So it's likely to be considered as broken:
- for multi-timezone applications
- for single-timezone applications using a different timezone than GMT
For instance, let's index 2016-01-01T00:00:00+01:00 and query
2016-01-01T12:00:00+01:00 with a DAY resolution:
- We'll index 2015-12-31 (2016-01-01T00:00:00+01:00 is
2015-12-31T23:00:00+00:00, which once truncated is 2015-12-31+00:00)
- We'll query 2016-01-01 (2016-01-01T12:00:00+01:00 is
2016-01-01T11:00:00+00:00, which once truncated is 2016-01-01+00:00)
That won't match, but from the point of view of a single-timezone user it
should have.
Of course I'm exaggerating a bit, and the issue probably hasn't been
noticed by many, because:
- there is no problem with the MINUTES, SECONDS and MILISECONDS
resolutions, which are not affected by timezones
- there is no problem with the HOUR resolution in most timezones (there
is a problem, however, when the timezone is something like -11:30)
- the problem is less likely to be detected when the user timezone is
close to GMT, because then only date/times close to midnight (i.e. outside
business hours) will be affected.
But my point is: the current solution produces counter-intuitive, sometimes
even useless results.
It was useful when dates were indexed as strings, but now that we (mostly)
index them as integers, this does not seem relevant. Even the DateTools
javadoc hints that DateTools (including "round") are not relevant for
numeric dates:
Another approach is {@link NumericUtils}, which provides
> a sortable binary representation (prefix encoded) of numeric values, which
> date/time are.
> For indexing a {@link Date} or {@link Calendar}, just get the unix
> timestamp as
> <code>long</code> using {@link Date#getTime} or {@link
> Calendar#getTimeInMillis} and
> index this as a numeric value with {@link LongField}
> and use {@link NumericRangeQuery} to query it.
What I'd like to propose is to deprecate or remove date/calendar
resolution, or limit it to STRING encoding, and instead encourage users to
query their dates with range queries whenever they don't want exact matches.
Of course we could also implement a way for users to customize the timezone
to be used when truncating. But range queries have other advantages:
- they fit the multi-timezone use case
- they allow to query the same field with multiple resolutions
At the very least, I'd like us to agree that in the future, we will only
implement automatic truncation with date/time types where the timezone is
either irrelevant or included (for instance ZonedDateTime or LocalDate or
LocalTime, but *not* Instant).
Relevant ticket: https://hibernate.atlassian.net/browse/HSEARCH-2378.
What do you think?
Yoann Rodière <yoann(a)hibernate.org>
Hibernate NoORM Team
8 years, 4 months
