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
10 years, 3 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.
10 years, 3 months
- 2
- 4