Re: [hibernate-dev] Everyone: Need volunteers for mentoring GSOC
Hi, Just a quick reminder: student's application phase starts next Monday, so if anyone feels like adding another proposal, you should do so now. The async stuff would be very interesting IMHO, but it'd need some more sharpening to make it operational for students. Cheers, --Gunnar 2016-03-06 17:29 GMT+01:00 Gunnar Morling : > Hi, > > 2016-03-06 14:03 GMT+01:00 Sanne Grinovero : >> On 5 March 2016 at 19:56, Gunnar Morling wrote: >>> Hi, >>> >>> I've added a proposal for "Hibernate Search: JSR 352 batch job for >>> re-indexing entities": >> >> Looks great! >> A couple more thoughts about this one: >> - should we suggest testing with different 2lc patterns, or keep it >> more open to suggest exploring additional ideas to push the indexing >> times down? > > I'd say let's leave it a bit more open, so students can add their own ideas. > > That said, what specifically do you have in mind here? I can see how > the 2nd level cache comes into play when re-indexing several entities > (e.g. A in its own index and another time via an @IndexedEmbedded > association B.A). Is this what you mean? > > I've shared a Google doc for this with you, please feel free to add > any thoughts in addition to what's in the public proposal. > >> - do we need to clarify that we expect people to load such entities >> through their (existing) Hibernate mappings? > > I don't think that's necessary right now. We can clarify these sorts > of things if applicants show up. > >> >> I can see how somebody might think he can do better by hand-rolling >> SQL, but the goal should be to have the framework figure out the >> optimal way without users having to maintain such SQL.. so this might >> optionally produce some more general purpose optimisations to >> Hibernate ORM's fetch strategy implementations. >> >> Most importantly: you're mentoring this one? > > Yes, I will, provided we find a student with high aspiration :) > >> >> Thanks, >> Sanne >> >>> >>> https://developer.jboss.org/wiki/JBossCommunityGoogleSummerOfCode2016Ideas#jive_content_id_Hibernate_Search_JSR_352_batch_job_for_reindexing_entities >>> >>> Any feedback welcome! >>> >>> Thanks, >>> >>> --Gunnar >>> >>> >>> >>> 2016-03-03 12:41 GMT+01:00 Gunnar Morling : Ahaha, ok. I took previous contribution as a given for active participants on hibernate-dev and people considering to mentor ;) Sorry I misread. 2016-03-03 12:38 GMT+01:00 Sanne Grinovero : > I asked for mentors, not students. > > On Thu, 3 Mar 2016 11:05 Gunnar Morling, wrote: >> >> Hi, >> >> I'll write up the proposal for the batch job for mass indexing and >> submit it to >> https://developer.jboss.org/wiki/JBossCommunityGoogleSummerOfCode2016Ideas. >> >> > It would need to be someone who's regularly contributing already... >> >> Personally I don't think that's needed and also it's not in the spirit of >> GSoC. >> >> The program is meant to bring students *into* OSS development. Of >> course having experience in that area doesn't harm, but it's no >> requirement. Much more important is the general attitude (willingness >> to learn etc.) as well as general programming knowledge. >> >> Student's applications start on March 14th, so whatever we feel like >> going for, should be in that proposal list by then. >> >> --Gunnar >> >> >> >> >> 2016-03-01 18:27 GMT+01:00 Sanne Grinovero : >> > Hi all, >> > earlier today in our IRC meeting [1] we discussed ideas for Google >> > Summer of Code; >> > mostly related Hibernate Search but not only: >> > >> > Quoting the previous summary by Gunnar: >> > 1 - Java Batch API job for HSEARCH mass indexing >> > 2 - Solr backend >> > 3 - HSEARCH support for JHipster >> > 4 - HSEARCH support for Spring Data >> > 5 - Async API for ORM/OGM/HSEARCH >> > [It's not a closed list, you can also propose additional ideas.] >> > >> > is anyone on this mailing list interested enough on these subjects to >> > volunteer mentoring? >> > >> > I mentored two students last year and we had nice results, but I won't >> > be able to mentor this summer. >> > >> > It would need to be someone who's regularly contributing already, and >> > ideally someone familiar with the technology we're integrating with: >> > most of the above proposals are about integrating with some other >> > standard or framework. >> > >> > For example I wouldn't mentor on JHipster as all I know about it is >> > what I've seen in a couple of presentations... but if the student is >> > not too junior he can also be tasked with reaching out to "the other" >> > community to get guidance. >> > >> > But for that I'd want us to be able to make some introductions at >> > least, to have some kind of "co-mentor" volunteered by the other >> > community/project. >> >
[hibernate-dev] HHH-10360 Natural ID columns are nullable by default (hbm mappings only)
I've created a pull request for this. [1] If it looks good I'd like to get the fix into 5.0.9. [1] https://github.com/hibernate/hibernate-orm/pull/1296 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH-8999/HHH-10413 and Comparable IDs
Version can be a byte[] ? I thought JPA was restricting version types
actually.
On Thu 2016-03-10 12:19, Gail Badner wrote:
> As I mentioned before, it is not acceptable for the comparator for
> PrimitiveByteArrayTypeDescripter to be IncomparableComparator because a
> version attribute can be of type byte[]. We definitely do not want all
> byte[] version values to compare as equal. A Comparator needs to be
> implemented at least for PrimitiveByteArrayTypeDescripter.
>
> I'm OK with changing getComparator() for
> PrimitiveCharacterArrayTypeDescriptor,
> ByteArrayTypeDescriptor, and
> CharacterArrayTypeDescriptor to return IncomparableComparator.INSTANCE. I
> think that is a safer option than B) (making
> IncomparableComparator.INSTANCE the default if the type is not assignable
> to Comparable).
>
> I'm also OK with using what I implemented in the pull request.
>
> On Thu, Mar 10, 2016 at 7:27 AM, Steve Ebersole wrote:
>
> > Personally I think using IncomparableComparator or null here makes the
> > most sense. I'm not really sure what the sort ordering of a byte array
> > would "mean".
> >
> > On Thu, Mar 10, 2016, 1:41 AM Gail Badner wrote:
> >
> >> I've created a pull request implements option A) (creates comparators
> >> for PrimitiveByteArrayTypeDescriptor,
> >> PrimitiveCharacterArrayTypeDescriptor, ByteArrayTypeDescriptor, and
> >> CharacterArrayTypeDescriptor.
> >>
> >> I'm still not sure if it makes sense to have a comparators for arrays.
> >>
> >> Steve, please take a look at the pull request [1] and let me know if this
> >> looks reasonable to you.
> >>
> >> Thanks,
> >> Gail
> >>
> >> [1] https://github.com/hibernate/hibernate-orm/pull/1294
> >>
> >> On Thu, Mar 3, 2016 at 2:44 AM, Gail Badner wrote:
> >>
> >> > Missed something. Please see below...
> >> >
> >> > On Wed, Mar 2, 2016 at 11:49 PM, Gail Badner
> >> wrote:
> >> >
> >> >> ExecutableList#add attempts to keep track of whether the Executable
> >> >> objects are sorted. [1]
> >> >>
> >> >> Except for entity insert actions (which use InsertActionSorter),
> >> >> ExecutableList#add uses the following to determine if adding the
> >> current
> >> >> Executable to the end invalidates the sort:
> >> >>
> >> >> if ( previousLast != null && previousLast.compareTo( executable ) > 0
> >> ) {
> >> >> sorted = false;
> >> >> }
> >> >>
> >> >> EntityAction#compareTo compares the IDs for the current and previous
> >> >> EntityAction if they have different entity names; similarly,
> >> >> CollectionAction compares the collection keys for the current and
> >> previous
> >> >> CollectionAction if they have different entity names.
> >> >>
> >> >> In most cases, the ID class implements Comparable, although I don't
> >> know
> >> >> of any requirement that says this needs to be true.
> >> >>
> >> >> This breaks down when a byte[] ID is used as described by HHH-8999. The
> >> >> reason is that AbstractTypeDescriptor#comparator is null because it is
> >> >> assigned like this:
> >> >>
> >> >> this.comparator = Comparable.class.isAssignableFrom( type )
> >> >> ? (Comparator) ComparableComparator.INSTANCE
> >> >> : null;
> >> >>
> >> >> PrimitiveByteArrayTypeDescriptor does not override
> >> >> AbstractTypeDescriptor#getComparator, so null is returned ultimately
> >> >> causing a NullPointerException in AbstractStandardBasicType#compare:
> >> >>
> >> >> public final int compare(Object x, Object y) {
> >> >> return javaTypeDescriptor.getComparator().compare( (T) x, (T) y );
> >> >> }
> >> >>
> >> >> The same happens for PrimitiveCharacterArrayTypeDescriptor,
> >> >> ByteArrayTypeDescriptor, and CharacterArrayTypeDescriptor. Are there
> >> others?
> >> >>
> >> >> According to HHH-10413, this also affects version attributes.
> >> >>
> >> >> Here are a couple of alternatives:
> >> >>
> >> >> A) create comparators for PrimitiveCharacterArrayTypeDescriptor,
> >> >> ByteArrayTypeDescriptor, and CharacterArrayTypeDescriptor.
> >> >>
> >> >
> >> > PrimitiveByteArrayTypeDescript should also be in the list for A).
> >> >
> >> >
> >> >>
> >> >>
> >> >> B) Change AbstractTypeDescriptor#comparator to:
> >> >>
> >> >> this.comparator = Comparable.class.isAssignableFrom( type )
> >> >> ? (Comparator) ComparableComparator.INSTANCE
> >> >> : IncomparableComparator.INSTANCE;
> >> >>
> >> >> IncomparableComparator#compare always returns 0, so that comparison
> >> would
> >> >> never invalidate the sort.
> >> >>
> >> >>
> >> > B) is not acceptable for PrimitiveByteArrayTypeDescripter because a
> >> > version attribute can be of type byte[]. We definitely do not want all
> >> > byte[] version values to compare as equal. A Comparator needs to be
> >> > implemented at least for PrimitiveByteArrayTypeDescripter.
> >> >
> >> > The following question only applies to
> >> > PrimitiveCharacterArrayTypeDescriptor, ByteArrayTypeDescriptor, and
> >> > CharacterArrayTypeDescriptor.
> >> >
> >> >
> >> >> Does it make sense to sort Executable obje
Re: [hibernate-dev] HHH-8999/HHH-10413 and Comparable IDs
Hibernate supports byte[] versions. You can see that
org.hibernate.type.BinaryType implements VersionType. [1]
The comment in BinaryType#seed says:
// Note : simply returns null for seed() and next() as the only
known
// application of binary types for versioning is
for use with the
// TIMESTAMP datatype supported by Sybase and SQL
Server, which
// are completely db-generated values...
There is also a unit test,
org.hibernate.test.version.sybase.SybaseTimestampVersioningTest that
maps:
[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/type/BinaryType.java
On Fri, Mar 11, 2016 at 7:36 AM, Emmanuel Bernard
wrote:
> Version can be a byte[] ? I thought JPA was restricting version types
> actually.
>
> On Thu 2016-03-10 12:19, Gail Badner wrote:
> > As I mentioned before, it is not acceptable for the comparator for
> > PrimitiveByteArrayTypeDescripter to be IncomparableComparator because a
> > version attribute can be of type byte[]. We definitely do not want all
> > byte[] version values to compare as equal. A Comparator needs to be
> > implemented at least for PrimitiveByteArrayTypeDescripter.
> >
> > I'm OK with changing getComparator() for
> PrimitiveCharacterArrayTypeDescriptor,
> > ByteArrayTypeDescriptor, and
> > CharacterArrayTypeDescriptor to return IncomparableComparator.INSTANCE. I
> > think that is a safer option than B) (making
> > IncomparableComparator.INSTANCE the default if the type is not assignable
> > to Comparable).
> >
> > I'm also OK with using what I implemented in the pull request.
> >
> > On Thu, Mar 10, 2016 at 7:27 AM, Steve Ebersole
> wrote:
> >
> > > Personally I think using IncomparableComparator or null here makes the
> > > most sense. I'm not really sure what the sort ordering of a byte array
> > > would "mean".
> > >
> > > On Thu, Mar 10, 2016, 1:41 AM Gail Badner wrote:
> > >
> > >> I've created a pull request implements option A) (creates comparators
> > >> for PrimitiveByteArrayTypeDescriptor,
> > >> PrimitiveCharacterArrayTypeDescriptor, ByteArrayTypeDescriptor, and
> > >> CharacterArrayTypeDescriptor.
> > >>
> > >> I'm still not sure if it makes sense to have a comparators for arrays.
> > >>
> > >> Steve, please take a look at the pull request [1] and let me know if
> this
> > >> looks reasonable to you.
> > >>
> > >> Thanks,
> > >> Gail
> > >>
> > >> [1] https://github.com/hibernate/hibernate-orm/pull/1294
> > >>
> > >> On Thu, Mar 3, 2016 at 2:44 AM, Gail Badner
> wrote:
> > >>
> > >> > Missed something. Please see below...
> > >> >
> > >> > On Wed, Mar 2, 2016 at 11:49 PM, Gail Badner
> > >> wrote:
> > >> >
> > >> >> ExecutableList#add attempts to keep track of whether the Executable
> > >> >> objects are sorted. [1]
> > >> >>
> > >> >> Except for entity insert actions (which use InsertActionSorter),
> > >> >> ExecutableList#add uses the following to determine if adding the
> > >> current
> > >> >> Executable to the end invalidates the sort:
> > >> >>
> > >> >> if ( previousLast != null && previousLast.compareTo( executable )
> > 0
> > >> ) {
> > >> >> sorted = false;
> > >> >> }
> > >> >>
> > >> >> EntityAction#compareTo compares the IDs for the current and
> previous
> > >> >> EntityAction if they have different entity names; similarly,
> > >> >> CollectionAction compares the collection keys for the current and
> > >> previous
> > >> >> CollectionAction if they have different entity names.
> > >> >>
> > >> >> In most cases, the ID class implements Comparable, although I don't
> > >> know
> > >> >> of any requirement that says this needs to be true.
> > >> >>
> > >> >> This breaks down when a byte[] ID is used as described by
> HHH-8999. The
> > >> >> reason is that AbstractTypeDescriptor#comparator is null because
> it is
> > >> >> assigned like this:
> > >> >>
> > >> >> this.comparator = Comparable.class.isAssignableFrom( type )
> > >> >> ? (Comparator) ComparableComparator.INSTANCE
> > >> >> : null;
> > >> >>
> > >> >> PrimitiveByteArrayTypeDescriptor does not override
> > >> >> AbstractTypeDescriptor#getComparator, so null is returned
> ultimately
> > >> >> causing a NullPointerException in
> AbstractStandardBasicType#compare:
> > >> >>
> > >> >> public final int compare(Object x, Object y) {
> > >> >> return javaTypeDescriptor.getComparator().compare( (T) x, (T)
> y );
> > >> >> }
> > >> >>
> > >> >> The same happens for PrimitiveCharacterArrayTypeDescriptor,
> > >> >> ByteArrayTypeDescriptor, and CharacterArrayTypeDescriptor. Are
> there
> > >> others?
> > >> >>
> > >> >> According to HHH-10413, this also affects version attributes.
> > >> >>
> > >> >> Here are a couple of alternatives:
> > >> >>
> > >> >> A) create comparators for PrimitiveCharacterArrayTypeDescriptor,
> > >> >> ByteArrayTypeDescriptor, and CharacterArrayTypeDescriptor.
> > >> >>
> > >> >
> > >>
