On 5 September 2013 08:27, Gunnar Morling wrote:
> I'm not yet understanding #1. When compiling against 4.2, wouldn't the new
> methods be missing or, if you added them, refer to types not being present
> with 4.2? How would this option exactly look?
Exactly, it would look lik as merging
https://
I'm not yet understanding #1. When compiling against 4.2, wouldn't the new
methods be missing or, if you added them, refer to types not being present
with 4.2? How would this option exactly look?
For the adapters to work in this particular case, I think you'd have to
move FTSI and FTEMI to the ada
To better explain the SessionDelegatorBaseImpl approach, I guess this
patch is worth 1000 words:
https://github.com/Sanne/hibernate-search/commit/a5dceffba58a1ea6a820e7fa5e11ecdffd079b96
7 additions and 704 deletions: that's a good improvement :-)
The real benefit is however in the strong decoup
That's one possibility, but to recap all options discussed so far:
One alternative which I consider quite tempting is that we don't
implement the new methods defined in Session and EntityManager (JPA
2.1), but keeping it fully compatible in all other ways.
We have this option because I resolved a
One option would be to (temporarily) establish an abstraction layer in
HSEARCH, which provides a uniform way for accessing the concerned
functionality from ORM.
You would then have two implementations of this layer, one based on 4.2 and
one based on 4.3 (e.g. in form of two separate HSEARCH module
There are some small changes in ORM 4.3 which are making HSearch
incompatible, while I'm trying to keep Search compatible with bith ORM
4.2.x and 4.3 series.
It's more complex than expected, so here is an update on what I'm doing:
# Shadowing of interfaces being moved to new packages
One change
