Hi Guillaume,
The problem is that the document id is indexed as a STRING field by
default, which is not matched by your sort type LONG.
To make it work, your options are:
* Use SortField.Type.STRING to match the field's type
* Index your id field as numeric field (which I suppose makes more
sens
Hi,
On Thu, Sep 24, 2015 at 09:23:20AM +0200, Gunnar Morling wrote:
> Either way, you should mark the field to sort on with @SortableField
> which will cause that field to get indexed as doc value field, making
> sorting much faster (see [1] and [2] for the details):
>
> @Id
> @NumericFie
> I don't think that just adding @NumericField will do, since it is just a
> companion
> annotation to @Field.
It does work (at least as of 5.5 where we fixed some issues around
@NumericField); It applies to the implicit document id field in this
case.
On Wed, Sep 23, 2015 at 03:54:30PM +, Steve Ebersole wrote:
> https://hibernate.atlassian.net/browse/HHH-10121
Nice +1
--Hardy
pgpQZEyT1BtEG.pgp
Description: PGP signature
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.
On Thu, Sep 24, 2015 at 10:28:14AM +0200, Gunnar Morling wrote:
> > I don't think that just adding @NumericField will do, since it is just a
> > companion
> > annotation to @Field.
>
> It does work (at least as of 5.5 where we fixed some issues around
> @NumericField); It applies to the implicit
Petar,
We're (at Terracotta) are currently working on our upgrading our internal
test suite to test Hibernate5.
Steve may obviously disagree, but I think upgrading in the next minor is
the best option, i.e. Hibernate 5.1.
I'll be working on making sure we have all testing being rolled out (i.e.
aut
Hi Hardy,
On Thu, Sep 24, 2015 at 10:47 AM, Hardy Ferentschik
wrote:
> Ok, still it makes modifications on the actual document id field, which
> should be avoided for the mentioned reasons.
OK. I must admit that as it worked well before, we didn't think a lot about
using the @DocumentId field
We really no longer maintain ORM 4.x. Yet we still get Jira reports citing
4.x as the affected version. We have been asking the reporter to reproduce
with 5.0.
But in the interim it is easy to lose track of these issues. Ultimately
the "affects version" needs to be updated or the issue rejected
Hello,
can someone please confirm this is a bug:
https://hibernate.atlassian.net/browse/HHH-10099
Or perhaps I'm doing something wrong?
If it really is a bug, I'll spend some more days debugging to see what's
happening, but if it's not I'd like to pointed why the order columns is not
generated.
Reference https://hibernate.atlassian.net/browse/HHH-10111
This comes down to the idea of a Type's mutability : can the thing's
internal state be changed? We use this for all kinds of optimizations. If
the internal state is not mutable, we know that "making a deep copy", for
example, is a simple
Petar, I guess it could be. I have not seen that myself nor reports of
that yet though.
On Thu, Sep 24, 2015 at 1:37 PM Petar Tahchiev
wrote:
> Hello,
>
> can someone please confirm this is a bug:
>
> https://hibernate.atlassian.net/browse/HHH-10099
>
> Or perhaps I'm doing something wrong?
>
I went ahead and resolved HHH-10111 to be correct in the mutable cases as
well. I created a new Jira[1] to continue the discussion related to
allowing the user to indicate that the type is immutable (as an
optimization), so let's move discussion of those follow-on steps to that
Jira.
[1] - https
12 matches
Mail list logo
