Andrew Smith created RYA-90:
-------------------------------
Summary: Refactor Configuration of Secondary Indexes
Key: RYA-90
URL: https://issues.apache.org/jira/browse/RYA-90
Project: Rya
Issue Type: Improvement
Reporter: Andrew Smith
I think the general goal of your tasking is to make query/insert configuration
independent of rya instance configuration (i.e a given rya prefix instance is
configured through the shell or a java instance management client, and a
query/insert client must conform to that configuration – it should not augment
it as it does now by creating tables if they don’t exist). A slightly less
important goal would be to streamline how configuration objects are created –
users should not be required to know the various configuration constants to
assign their property values to in order to create a Sail Connection. Giving
the appropriate attention to streamlining configuration prolly falls a little
outside the scope of your tasking, but would be very nice.
Kevin and I agree that a blacklist approach for the index configuration would
probably be best (as opposed to the white list/overwrite approach that you’re
using). By blacklist, I mean that a query client will by default be configured
to use all available indexing services unless they turn them off, as opposed to
a whitelist approach where the user specifies which indexing services they
want. This works nicely because it avoids the situation where the user
specifies an indexing service that doesn’t exist. Of course, certain things
will have to be white listed like reasoning, and maybe Pcj Table Names if a
user wants to specify a subset of Pcj Tables. Andrew or Puja, if either of you
feels strongly that this isn’t a good approach, please weigh in. I suppose we
can discuss pros and cons on Thursday. Regarding inserts, the user
configuration should not be taken into account. The AccumuloRyaDAO should use
the admin table client to determine which index tables exist when adding
triples. If a user wants to turn indexing on or create tables for a given rya
prefix instance, they should be forced to do that through the shell or instance
management client.
Regarding the visitor that we discussed, use the static method getTupleSets
found at
https://github.com/apache/incubator-rya/blob/develop/extras/indexing/src/test/java/mvm/rya/indexing/external/PcjIntegrationTestingUtil.java.
If the client is configured to use any indexers, the appropriate nodes in the
query plan are replaced by some subclass of ExternalTupleSet. Take a look at
the query plans that are printed out in RyaDirectExample in the project
rya.indexing.example to get a sense of what I mean. This visitor gets all
instances of ExternalTupleSets that appear in your query plan. So if the
indexing tables exist and the client is configured to not use an index, the
above method should return an empty list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
