Having LARQ is Fuseki is really valuable IMHO.
Using the new LARQ keeps Lucene indexes up-to-date with TDB and it
avoids
duplicates. This, IMHO, is another really valuable thing for LARQ users.
Not disagreeing but there seems to be no migration plan or documentation.
If we leave the old/legacy LARQ in ARQ as it is, no migration plan is
necessary.
People can decide which one to use.
I thought that indexes built with ARQ do not work with LARQ ones due to
the new field. At least, flipping between the two could cause issues?
What describing about assembler file changes to connect the text index
to the dataset?
Documentation: yes, necessary but there are no actual changes from an
API or
use point of view. For developers, I'll document how to add a dependency on
LARQ artifacts if they want to use the new/separate module.
Why don't we just switch to LARQ now?
I'd prefer to add LARQ to Fuseki first, so that we can make it easier for
people to try it out, they can report us feedback and if it's ok we can
then remove the old LARQ from ARQ.
I'm not sure how much feed back that'll produce.
Fuseki is distributed as a complete jar as well as via maven. As a
complete jar, it won't have LARQ in it, would it? So used that way, the
most common way, won't exercise LARQ?
And the assembler description needs to change to activeate the index so
even if it's included, the user has to do something to get it's benefits.
Leaving LARQ in ARQ minimize risk and changes and it offers a fall back
to people.
If it's not automatic (Lucene3 can read Lucen2 indexes?), then we need
to document how the user can do an upgrade.
The new LARQ adds a new field to the Lucene index (i.e. "hash") to support
unindex/deletes, see [1], therefore a reindex (using the usual larqbuild is
necessary).
I think that needs explaining somewhere + the assembler changes, or
people may not realise the benefits of LARQ.
Paolo
