Re: [hibernate-dev] [Search] Something fishy with sort by id

2015-09-24 Thread Gunnar Morling 
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
sense for your use case) in which case you can use sort type LONG:

@Id
@NumericField
private Long id;

Of course you also could keep the default String field and add a
second, numeric field for sorting.

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
@NumericField
@SortableField
private Long id;

As a side-effect, this will expose the mismatch between field and sort
type through an exception upon query time. We assumed this would also
be the case with index uninverting (which is used without
@SortableField) but apparently that's not happening. There is an issue
[3] for improving that. HSEARCH should detect the mismatch itself
before letting Lucene run the query.

Cheers,

--Gunnar

[1] see http://staging.in.relation.to/2015/09/14/sorting-in-hibernate-search-55/
[2] http://hibernate.org/search/documentation/migrate/5.5/#sorting-options
[3] https://hibernate.atlassian.net/browse/HSEARCH-1951


2015-09-23 23:18 GMT+02:00 Guillaume Smet :
> And if I sort by creationDate desc, the sort is OK. So I really think
> there's something related to sorting on the id.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search] Something fishy with sort by id

2015-09-24 Thread Hardy Ferentschik 
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
> @NumericField
> @SortableField
> private Long id;

To expand on this - you should not make any assumptions on the id field
or use it for indexing etc. We talked for a long time that we want to prevent
users to use the internal Search document id in queries and for sorting.
This would allow for optimizations of how for example the id is stored and
encoded.

If you need the id value for searches and/or sorting you should use additional
@Field annotations (using @Fields if you need more than one field). So in your 
case you would for example add @Field(name="id_sort", ...). This is the most
future proof solution. 

I don't think that just adding @NumericField will do, since it is just a 
companion
annotation to @Field.

--Hardy



pgp92ON5rvnCD.pgp
Description: PGP signature
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search] Something fishy with sort by id

2015-09-24 Thread Gunnar Morling 
> 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.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] No ValidatorFactory exposed through "javax.persistence.validation.factory" in WF 10 CR1

2015-09-24 Thread Hardy Ferentschik 
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.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search] Something fishy with sort by id

2015-09-24 Thread Hardy Ferentschik 
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 document id field in this
> case.

Ok, still it makes modifications on the actual document id field, which
should be avoided for the mentioned reasons.

--Hardy


pgpJ4lktWg8d8.pgp
Description: PGP signature
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Cache

2015-09-24 Thread Alex Snaps 
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.
automated et al) in time for that.
I have created HHH-10124  for
tracking this.
Alex

On Tue, Sep 8, 2015 at 4:21 PM Steve Ebersole  wrote:

> Petar,
>
> The Ehcache developers actually maintain that hibernate-ehcache module.
> Alex has told me that the API is stable across all of those versions,
> meaning that you can drop any of those versions you mentioned alongside
> hibernate-ehcache and it will JustWork(tm).
>
> That said, I know Alex is working on jcache based integration with
> Hibernate caching.
>
>
>
> On Thu, Sep 3, 2015 at 1:20 PM Petar Tahchiev 
> wrote:
>
> > Currently hibernate-ehcache depends on ehcache 2.4.3:
> >
> >
> >
> http://repo1.maven.org/maven2/org/hibernate/hibernate-ehcache/5.0.0.Final/hibernate-ehcache-5.0.0.Final.pom
> >
> > which is more than 4 years old In the meantime there has been 22
> > releases on the 2.x version and currently a 3.0.0.m2 on the 3.x version
> > here:
> >
> > http://repo1.maven.org/maven2/org/ehcache/ehcache/3.0.0.m2/
> >
> > The ehcache 3.x now supports jcache and is completely rewritten from
> what I
> > understand. Are there any plans to have this updated? For example I'd
> like
> > to use hibernate with any jcache cache, but I currently I can't use
> > ehcache, or hazelcast (because of this issue
> > https://github.com/hazelcast/hazelcast/issues/5633). I believe it's
> > important to support multiple caching solutions.
> >
> >
> > --
> > Regards, Petar!
> > Karlovo, Bulgaria.
> > ---
> > Public PGP Key at:
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search] Something fishy with sort by id

2015-09-24 Thread Guillaume Smet 
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 for sorting :).

I'll go clean up our applications!

Thanks.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Jira issues reported against 4.x

2015-09-24 Thread Steve Ebersole 
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 as
out-of-date.  To help keep track of them, I created a new label:

https://hibernate.atlassian.net/browse/HHH-10106?jql=labels%20%3D%20verify-affects-5.0
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] HHH-10099

2015-09-24 Thread Petar Tahchiev 
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.

Thanks.

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] AttributeConverter and internally mutable domain types

2015-09-24 Thread Steve Ebersole 
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 matter of just returning the original.  It also
affects how we dirty check it, how we (2nd level) cache it, etc.

So far we have assumed that types mapped using AttributeConverters are
immutable.  However, this Jira is an example of where that breaks down.

I think for now we will have to assume that the AttributeConverter entity
type is mutable and build an appropriate MutabilityPlan.  Moving forward I
think we should consider a means to allow developers
using AttributeConverter along with immutable state (which seems to be the
majority case) the option to somehow indicate that the converted-to type is
immutable which allows us to apply the more efficient plan.  Thoughts on
the best way to achieve this latter part?  I am initially thinking an
optional contract for the AttributeConverter impl itself to implement:

@Converter
class MyAttributeConverter
implements AttributeConverter,
HibernateAttributeConverter {
// normal AttributeConverter methods

/**
 * HibernateAttributeConverter
 */
@Override
public boolean isMutable() {
return true;
}
}

Another option is to develop some annotations that are applied to the
AttributeConverter impl (much like the javax.persistence.Converter itself):

@Converter
@org.hibernate.annotations.MutableConvertedState(true|false)
class MyAttributeConverter implements AttributeConverter {
// normal AttributeConverter methods
}
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-10099

2015-09-24 Thread Steve Ebersole 
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?
> 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.
>
> Thanks.
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] AttributeConverter and internally mutable domain types

2015-09-24 Thread Steve Ebersole 
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://hibernate.atlassian.net/browse/HHH-10127

On Thu, Sep 24, 2015 at 2:08 PM Steve Ebersole  wrote:

> 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 matter of just returning the original.  It also
> affects how we dirty check it, how we (2nd level) cache it, etc.
>
> So far we have assumed that types mapped using AttributeConverters are
> immutable.  However, this Jira is an example of where that breaks down.
>
> I think for now we will have to assume that the AttributeConverter entity
> type is mutable and build an appropriate MutabilityPlan.  Moving forward I
> think we should consider a means to allow developers
> using AttributeConverter along with immutable state (which seems to be the
> majority case) the option to somehow indicate that the converted-to type is
> immutable which allows us to apply the more efficient plan.  Thoughts on
> the best way to achieve this latter part?  I am initially thinking an
> optional contract for the AttributeConverter impl itself to implement:
>
> @Converter
> class MyAttributeConverter
> implements AttributeConverter,
> HibernateAttributeConverter {
> // normal AttributeConverter methods
>
> /**
>  * HibernateAttributeConverter
>  */
> @Override
> public boolean isMutable() {
> return true;
> }
> }
>
> Another option is to develop some annotations that are applied to the
> AttributeConverter impl (much like the javax.persistence.Converter itself):
>
> @Converter
> @org.hibernate.annotations.MutableConvertedState(true|false)
> class MyAttributeConverter implements AttributeConverter {
> // normal AttributeConverter methods
> }
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev