[HV] Jumping to HV 6?
by Gunnar Morling
Hi,
Now that the first changes in HV are being made towards BV 2.0, one
question is which version of HV that should be.
For BV we are doing a major version jump from 1.1 to 2.0 as the minimum
Java version is raised. So I'm suggesting to do the same for HV and jump to
a new major, HV 6. We also may get rid of some HV-specific SPIs and replace
them with ones standardized in BV 2.0, which are breaking changes by their
nature and thus also justify the new major*.
Assuming we agree on moving to HV 6 for BV 2.0, what should happen to the
current 5.3 family? We did an Alpha of it a while ago. Just leaving it
behind like that would look very bad IMO. So I'm inclined to release a
quick CR + Final, essentially containing what has been done prior to the BV
2.0 work (plus maybe some more bug fixes). That should happen rather
quickly so we can focus on HV 6.
Also WF could get that next 5.3 to contain the latest fixes of the BV 1.1
RI.
If there are no objections to that plan, I'd move forward with it and aim
for 5.3.CR1 release some time next week.
Thanks,
--Gunnar
* ResourceBundleLocator comes to mind which would be obsolete in its
current form when splitting up the notions of message interpolation and
resource bundle retrieval
9 years, 7 months
[HSEARCH] Google Summer of Code: JSR 352 batch job for re-indexing entities
by Mincong Huang
Hi everyone,
I’m Mincong, an engineering student from France. I’m glad to present my
Google Summer of Code 2016 project, which provides an alternative
to the current mass indexer implementation of Hibernate Search, using
the Java Batch architecture (JSR 352). I’ve been working on this project
for 4 months. You can see the blog post in the below link:
http://in.relation.to/2016/08/22/new-implementation-of-mass-indexer-using...
I want to express to each of you my heartfelt thanks.
My mentor, Gunnar Morling for his involvement, advice and availability
throughout the project. He’s always well-prepared before the next meeting
and understand the context quickly. His advices are concise and very
useful. I highly recommend him as a mentor for any other GSoC students.
My mentor, Emmanuel. He's my second mentor during the holiday of
Gunnar. He did a great job too. We’ve 2 physical meetups at Paris and he
brought many advices in the persistence side, which ensures the code
quality and introduces some new algorithms for the project.
All the members of Hibernate Search. It was a fantastic and rewarding
experience. I'll stay with you and contribute more source code to this
project and probably other projects of hibernate.
Best regards,
Mincong Huang
9 years, 7 months
Treat support
by Christian Beikov
Hello,
I am sorry if this was already discussed somewhere but I couldn't find
anything on the internet about this.
I am currently working on some testcases for the treat
operator(https://github.com/beikov/jpa-treat-variations) that are
apparently missing in the TCK as most JPA providers fail them. I'd like
to offer them to you to be integrated into the hibernate testsuite.
Could you maybe run that locally and comment on the test cases? I am not
100% sure that my understanding of what treat should do is right, but I
tried to explain the reasoning for the expected test results inline.
The following points I found out during my testing.
* Missing support for treated paths like "TREAT(...).property" in the
parser. This is more or less workaroundable for non-root path
treats. Since root paths can't be treat joined to my knowledge, some
treated paths simple can't be used. Maybe in 90% of the cases
hibernate will just resolve to the right property without needing
the treat?
* Missing support for a special case of treat join which apparently
was overseen by the JPA spec which would be "TREAT(TREAT(rootPath AS
Subtype).relation AS RelationSubtype)". Eclipselink not only allows
this syntax but for inner joins also implements the appropriate
logic. I am thinking that this might even work in hibernate without
the inner treat, but would fail for attributes with same names.
* Joins for supertypes and conditions on discriminators are not aware
of the join type actually used in the treated join => left join
should cascade up the type hierarchy and discriminator checks should
contain OR DTYPE IS NULL for left join semantics. If treats are in
subconditions the DTYPE checks might even be wrong
* Joins are generated for the whole hierarchy not only the types that
are treated => this might seem to be "just" a performance problem,
but IMO actually is a correctness problem as it makes a difference
if you get e.g. 2 rows or 2 * TYPES rows especially for count queries.
What I would like to know is if these bugs are planned to be tackled in
Hibernate 6+ only or if they are considered for 4.3, 5.0, 5.1, 5.2 too.
Are these things too hard to fix without SQM or do capable people just
lack time or interest to implement this?
--
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
9 years, 7 months
Locale to/from String
by Steve Ebersole
I have had a comment in LocaleType for quite some time to convert
fromString handling to use the Locale.Builder introduced in Java 7. As
part of the 6.0 work I took a quick look at this.
I think we handle this incorrectly for certain cases currently.
Currently we implement toString(Locale) via Locale#toString, where the
authors specifically say "If both the language and country fields are
missing, this function will return the empty string, even if the variant,
script, or extensions field is present (you can't have a locale with just a
variant, the variant must accompany a well-formed language or country
code)."
However in fromString we actually allow for such cases. Consider this test:
assertEquals(
"___ch123",
LocaleTypeDescriptor.INSTANCE.toString(
LocaleTypeDescriptor.INSTANCE.fromString( "__ch123" )
)
);
This actually ends up failing. The assertion fails.
LocaleTypeDescriptor.INSTANCE.fromString(
"__ch123" ) does in fact parse us a Locale with no language, no
country/region and a variant of "ch123". In fact if I check the Locale
fields individually they are all set that way.
However, as per that javadoc note, the call to LocaleTypeDescriptor#toString
(Locale#toString) returns "".
So the question becomes what we want to support here. If the described
Java behavior is to not allow a Locale with just a variant (no language nor
country/region) I think we may want to enforce that here too.
Thoughts?
9 years, 7 months
Build failure when building 5.1.1.Final
by Gail Badner
I'm getting a build failure. [1]
Unless someone gets back to me shortly to help, I will have to postpone
releasing 5.1.1.Final until Monday.
Regards,
Gail
[1]
POM relocation to an other version number is not fully supported in Gradle
: xml-apis#xml-apis;2.0.2 relocated to xml-apis#xml-apis;1.0.b2.
FAILURE: Build failed with an exception.
* Where:
Build file
'/home/gbadner/git/hibernate-orm-5.1.1/hibernate-orm-modules/hibernate-orm-modules.gradle'
line: 146
* What went wrong:
A problem occurred configuring project ':hibernate-orm-modules'.
> Exception thrown while executing model rule:
org.gradle.api.publish.maven.plugins.MavenPublishPlugin$Rules#realizePublishingTasks(org.gradle.model.collection.CollectionBuilder<org.gradle.api.Task>,
org.gradle.api.Task, org.gradle.api.Task,
org.gradle.api.publish.PublishingExtension) >
create(publishMavenJavaPublicationToJboss-releases-repositoryRepository)
> Cannot get property 'name' on null object
9 years, 7 months
Hibernate ORM version for WildFly 10.1
by Gunnar Morling
Hi Scott, all,
Are there any plans to upgrade ORM in the WF 10.1 release?
I somehow assumed that 10.1 would come with ORM 5.1, but it's still using
5.0.9. At least 5.0.10 would be nice if 5.1 cannot be done for some reasons.
Thanks,
--Gunnar
9 years, 7 months
