[SEARCH] Integration of Mincong's work on adding JSR-352 support
by Yoann Rodiere
Hello,
Following our recent (and successful) efforts to fix blocking issues on
https://github.com/mincong-h/gsoc-hsearch/, I recently added a branch on my
repo which contains the Hibernate Search codebase, with the addition of a
JSR-352 submodule. You can find the branch at [1]. The build is working
just fine ([2]).
I tried to preserve as much metadata as possible when building this branch,
without keeping a long list of commits that would probably do more harm
than good. Basically I squashed commits and put the git log of the squashed
commits in the commit's comment. I tried to preserve authorship and
approximate dates, so git blame will still be useful.
If this branch seems acceptable to everyone, we can start working on
further polishing the JSR-352 integration, and eventually merge it. Below
are the next few steps to discuss.
# What's left to do
The full list of remaining issues can be found on the original repo [3]. I
marked as "Blocker" those issues that seem unacceptable in a release.
To sum up:
- we have some APIs that will need further refining (just a few);
- we basically don't have any documentation (there is a start, but it's
already obsolete);
- we lack some tests, most notably integration tests with other
implementations than JBeret;
- composite IDs are not supported correctly;
- there are performance issues (or at least there were last time we
checked);
- failure recovery doesn't seem to be implemented correctly (uses
AddLuceneWork instead of UpdateLuceneWork for the failing partition);
- there are still questions about how transaction timeouts should be
handled.
# Organization
I'd like to avoid merging the branch to master as long as the module isn't
ready. Here's why:
1. The module isn't ready for prime-time yet (see above)
2. The module is only loosely tied to Hibernate Search, in a few very
specific portions of the code, so rebasing it shouldn't be hell. And it'll
probably be me doing it anyway ;)
So think we should leave the code where it is now (a branch on my repo, see
[1]) and manage pull requests there.
About CI, Travis is working just fine for me, and since we're working on an
additional module the changes we make shouldn't have any impact on the
core. So I don't think setting up a job on ci.hibernate.org is required yet.
Regarding the tickets, I would create issues in our JIRA based on the
existing GitHub issues in the original repo. Probably make them sub-tasks
of HSEARCH-2594 [4]. I'll work on this later this week if nobody is against
it.
As to the planning, I'd say our problem isn't so much the amount of work
(there shouldn't be much more than 2 or 3 man-weeks remaning) than the
amount of time we can put into it.
Mincong isn't studying anymore and has a full-time job; however, he
generously proposed to work on this during his week-ends. But it obviously
wouldn't be reasonable to expect him to work on this every week-end, all
week-end long.
As for Sanne and myself, we'll be working on ES5 integration + Search 5.8 +
Search 6, so we also have a lot to do. I think I'll book some time slots (1
day a week maybe) to work on JSR-352 until we consider the module ready.
Any opinions on all this?
[1] https://github.com/yrodiere/hibernate-search/tree/jsr352
[2] https://travis-ci.org/yrodiere/hibernate-search/builds/203727344
[3] https://github.com/mincong-h/gsoc-hsearch/issues
[4] https://hibernate.atlassian.net/browse/HSEARCH-2594
Yoann Rodière <yoann(a)hibernate.org>
Hibernate NoORM Team
8 years, 10 months
HHH-11089
by Petar Tahchiev
Hey guys,
a while ago I opened this issue:
https://hibernate.atlassian.net/browse/HHH-11089
which blocks me from using Hibernate with Oracle database (the well-known
issue with 30 chars limit for table/column/foreignkey/indexkey names).
While I managed to workaround the tablename/columnname by specifying a
custom PhysicalNamingStrategy. I also created a custom
ImplicitNamingStrategy, but figured out it is never invoked when I have
already specified a name for the foreign-key/indexkey. It is only called
when no name has been given for the foreign key or index. I made a pull
request, and you guys asked for some improvements.
Long-story-short I just committed my improvements:
https://github.com/hibernate/hibernate-orm/pull/1564/commits/78edc44143e3...
to make sure that the implicit naming strategy is always invoked no matter
if the user has specified a name for the foreign key or have omitted it.
Can someone please review it?
BTW I'm not able to build the 5.1 branch and my branch too because I get
thousands of checkstyle violations in files that I haven't worked on. I
also tried to exclude the checkstyle plugin but seems like my gradle
knowledge wasn't enough.
Thank you and keep up the good work :)
--
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
8 years, 10 months
dynamic instantiation queries
by Steve Ebersole
Historically (well before JPA) HIbernate would handle dynamic instantiation
queries in cases where one of the arguments being an entity-reference by
passing just the entity's identifier rather than a complete reference to
the entity. To be clear, I am talking about a query like:
select new DTO( p ) from Person p
Hibernate implicitly treats this like:
select new DTO( p.id ) from Person p
and expects DTO to have a ctor taking the appropriate ID type.
JPA came along and also defines support for dynamic instantiation queries,
but does not specify one way or the other how this case should be handled.
I have been told other providers interpret this the opposite way. Makes
sense. I think it is time we at least allow that as an option. Or maybe a
nicer implementation that looks for both and picks the available one (if
that's not too much effort).
What do y'all think?
8 years, 10 months
@Where clause and finding an entity
by Vlad Mihalcea
Hi,
I'm testing the way @Where annotation works, and I found the following
scenario:
If we have an entity annotated like this:
@Where(clause = "deleted = false")
@SQLDelete(sql = "UPDATE tag set deleted = true where id = ?")
If the entity was previously deleted and I try to load it in a new
Persistence Context:
assertNull(entityManager.find(Tag.class, "Misc"));
The entity is fetched successfully, and the assert fails.
The only way to make it work is if I override the load query using the
@Loader annotation:
@Loader(namedQuery = "findTagById")
@NamedQuery(name = "findTagById", query = "select t from Tag t where
t.id = ? and t.deleted = false")
Is this the expected behavior or is it a bug?
Vlad
8 years, 10 months
New project, new group-id: org.hibernate.lucene-modules
by Sanne Grinovero
Hi all,
I'm proposing the use of the `org.hibernate.lucene-modules` group id
for the stuff which we'll be releasing from this repository:
- https://github.com/hibernate/lucene-modules
Context: Hibernate Search has been packaging Apache Lucene as a
WildFly module, essentially including the Lucene modules as part of
the Hibernate Search modules.
We want to separate these modules, for various reasons; the main
driver being the build of Infinispan is much simpler if they can
source the Lucene modules "out of band" from the Search release
version. Sometimes we need some more flexibility, and it's getting
close to mission impossible to workaround the tight coupling.
This might also help other projects use Lucene when not necessarily
interested in Hibernate Search, or in using the Lucene versions which
Search would allow (a subset of the Lucene releases).
Finally, since we release these modules with name "org.apache.lucene",
it might just make sense for them to be independent and just contain
Apache Lucene.
If you're interested more details, have a look at PR number 1:
- https://github.com/hibernate/lucene-modules/pull/1/files
In Hibernate Search this would imply:
- https://github.com/Sanne/hibernate-search/commit/a271d43d15b6af508ea693b3...
Thanks,
Sanne
8 years, 10 months
DB2 cross joins
by Gail Badner
HHH-11487 can be fixed by using changing DB2Dialect#getCrossJoinSeparator
to return " cross join ".
DB2 9.1 did not support CROSS JOIN, but DB2 9.5 and later do support CROSS
JOIN. I see that DB2 9.1 is no longer supported as of April 30, 2015.
It's tempting to just update DB2Dialect, but I suspect that would break
existing applications still using DB2 9.1.
I'm considering adding a new dialect DB295Dialect that extends DB2Dialect
and overrides DB2Dialect#getCrossJoinSeparator to return "cross join".
WDYT?
Regards,
Gail
8 years, 10 months
Hibernate Validator 6.0.0.Alpha1 is out with initial Bean Validation 2.0 support
by Guillaume Smet
Hi,
It's with great pleasure that I announce the release of Hibernate Validator
6.0.0.Alpha1.
This release is coordinated with the Bean Validation 2.0 Early Draft 1
release that happened earlier this week [1].
Hibernate Validator 6 will be the reference implementation of Bean
Validation 2.0, but it's also a place to experiment with the future
additions to the spec.
Apart from initial Bean Validation 2.0 support, this version comes with a
lot of good things:
- some Java 8 goodness,
- nested type use constraints and nested cascaded validation
- lambda based constraint definition
- Duration support (and a much improved java.time support coming as part of
Bean Validation 2.0)
As explained in the announce on in.relation.to [2], we are looking forward
to your feedback on these features. They might be refined and included in
the next Bean Validation 2.0 iteration if they get enough traction.
Have a nice day!
[1]
http://beanvalidation.org/news/2017/02/14/bean-validation-2-0-early-draft...
[2] http://in.relation.to/2017/02/16/hibernate-validator-600-alpha1-out/
8 years, 10 months
