[jira] [Commented] (RYA-90) Refactor Configuration of Secondary Indexes

["Puja Valiyil (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RYA-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15435253#comment-15435253 ] 

Puja Valiyil  commented on RYA-90:
----------------------------------

Is this resolved by RYA-81 or RYA-82?

> 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)