Why backports to Hibernate Search 4.4 branch?
by Sanne Grinovero
I've been asked on github's review comments why I'm still backporting
trivial fixes to the 4.4 branch;
moving the conversation to the mailing list:
We created the 4.5 branch because it was impossible to support both
ORM series 4.2 and 4.3, so a 4.5 release train was highly needed to
not prevent people to move onto WildFly and our latest ORM versions.
Still considering that JPA 2.1 is very new, I think it's fair to state
that our largest pool of users is using JPA 2.0 at present; of course
I'm not counting those on very old unmaintained versions as they are
unlikely to download a new version of Search or reported any issue
anyway.
So there still is a large interest, not least some of our very best
contributors, presently using ORM 4.2 and JPA 2.0, AND actively using,
debugging and reporting issues on Hibernate Search 4.4 (see for
example Guillaume's email of today).
Also, we have products to support for a very long term which are based
on this stable 4.4 branch: backporting occasional trivial issues makes
our maintenance capabilities better.
We don't promise that all fixes will be backported, and we'll probably
apply fixes only "as needed" by a specific request, but if there is
something which is definitely broken and so trivial to fix like [1], I
simply think it's easier to cherry-pick right away rather than
tracking some additional TODOs ;-)
It is also possible that we'll do more 4.4 releases as needed. Of
course I don't wish to spend too much of our effort on it, but if it's
an easy task, I don't see why we should deny it.
[Finally, I'm taking organizational steps to make such releases have
no impact on our time, so it's a win-win for everyone.. more news to
follow]
Cheers,
Sanne
1 - https://github.com/Sanne/hibernate-search/commit/f34a61e90b7dbec38a01f0a7...
12 years, 2 months
- 1
- 0
Hibernate Search 5: heavy refactoring in progress!
by Sanne Grinovero
Hi all,
I'm heavily committing on my Lucene 4 branch.
It doesn't compile yet, and many commits are "temporary scaffolding"
designed to be removed at further rebase phases, so I'm NOT advising
to fork it unless you want to have a look. Comments are very welcome
of course :-)
Also, I'm trying to iterate on previous changes while my knowledge in
the new Lucene internals improves, so I'm reviewing and rewriting my
history several times each day.
This is my current strategy:
I'm favoring quick and simple changes - when possible - to get it all
to a phase in which it can compile successfully.
I need it quick so to minimize the time
- in which I don't have tests feedback
- in which collaboration with other volunteers is harder
Therefore I'm adding quite some TODO and FIXME notes, rather than
opening JIRAs: my plan is to resolve all TODOs before my branch is in
decent enough shape for a pull request, or for those tasks that
conflict with the "minimal time" requirement will be converted in
JIRAs.
Among other significant changes in Lucene4, many packages have been
renamed. For these, I'm crafting the patches as a form of living
document of required changes, that could be helpfull for compiling a
migration guide for our users; see for example the commit comment at:
https://github.com/Sanne/hibernate-search/commit/036539ad432f24e47128d0a6...
I'm primarily working on the -engine module, so that as soon as this
one is looking good enough we can parallelize refactoring on dependent
modules. Note that Infinispan 6.0 already supports Lucene 4, so
getting "engine" converted is the only dependency to unlock work on
all other modules.
https://github.com/Sanne/hibernate-search/compare/evolveLucene4
- Sanne
12 years, 2 months
- 1
- 1
JdbcSession -> DataStoreSession
by Steve Ebersole
As Gail and I discussed the actual API to use in this JdbcSession
redesign we both liked the idea of sending Operations in to the
JdbcSession rather than JdbcSession exposing a very granular, JDBC-like
API. This got me to thinking that JdbcSession really could be a generic
representation of a connection+transaction context for *any* back end,
whether that back-end was JDBC or not.
I discussed this idea a bit with Sanne on IRC. He was on board in the
general sense.
So this morning I spent some time re-working the code to express this
concept. I just pushed this out to my repo. The main contract now is
org.hibernate.resource.store.DataStoreSession. The JDBC realization of
this contract is defined by
org.hibernate.resource.store.jdbc.JdbcSession (which extends the
DataStoreSession).
The nice thing is that this all ties in seamlessly with the
TransactionCoordinator. There is a notion of "resource local
transactions" and "jta transactions". "resource local transactions"
ultimately come from the DataStoreSession which allows integrating
back-end specific notions of transactions by implementing a
org.hibernate.resource.transaction.ResourceLocalTransaction for that
back end (org.hibernate.resource.store.jdbc.spi.PhysicalJdbcTransaction
for example for JDBC).
Anyway, it was a nice exercise even if y'all decide to not use this in
OGM. It forced me to think about the separation between the 2 main
packages (org.hibernate.resource.transaction versus
org.hibernate.resource.store) and to remove the cyclic deps.
12 years, 2 months
- 2
- 4