Applied Van's change to remove the property.

created PR https://github.com/teiid/teiid/pull/306

This doesn't appear to have been done yet. Do you want me to alter the ra.xml files or is this being done as part of the other work?

I'll remove the resource-adapter property and undo what was added. Then create a translator that reads the metadata from the protobuf and add the query logic that performs the DSL searching.

Van any additional thoughts on the above?

Also, part of the thinking is to make the cacheWrapper like a jdbc driver. In a database, it performs the query the best it can, and I would assume the cache query execution would do the same. The user/translator doesn't need to know what's the best option in order to issue a query. If they need to know that, they could look at how the cache is configured. Additionally, ask the wrapper for the metadata. I know you don't want to push the language objects into connector. Then an option could be , in the translator, could use a visitor to obtain what's needed to pass as the query. Similar to what other translators do when they construct data source specific query.

Related to using protobuf's, its recommended by infinispan to use the following logic to obtain the metadata:

import org.infinispan.client.hotrod.marshall.ProtoStreamMarshaller;
import org.infinispan.client.hotrod.RemoteCacheManager;
import org.infinispan.protostream.SerializationContext;
...
com.google.protobuf.Descriptors.Descriptor descriptor = ProtoStreamMarshaller.getSerializationContext(remoteCacheManager).getMessageDescriptor("

");

The descriptor has a getJavaType() method that will be used, instead of doing reflections, as is done in the object translator.

Now, if this logic is pushed into the translator, it brings a lot of dependencies. And on the other had, if put into the connector, I was thinking the cacheContainerWrapper as the means to expose this info, as the connection has access to this object.

> The configuration of the resource adapter is there, then why not add what it supports too.

Because that is still coming from a JBoss/Teiid admin, not the source system itself. Also it depends on whether we see there being only two states here (if there indexes, use lucene. if not, then don't) or if there is a third state (don't use the indexes even if present). If the third one is a possibility it would make sense then that there was a translator level switch - unless you are assuming that there is a one-to-one correspondence between resource adapter instance and translator instances.

> I really think, the function of querying (e.g. by key, lucene or DSL) should be moved into the cache wrapper, so the translator doesn't need to control how its performed.

I don't see a lot of benefit in doing this. Basically all we would be doing is moving Teiid language api dependencies down into the resource adapter.

> And with the addition of DSL support and the dependencies on google protobuf's, if we don't segment this more, there will be no separation between the translator and resource adapter.

I don't completely follow this. The separation between the translator and resource adapter is that the resource adapter should be abstracting how we access the resource. I'm not sure how the abstraction changes with DSL support, can you elaborate?

What I can gather is that your preferred end state would look like a thin translator and a resource adapter that understands our query objects and makes all of the decisions from there.

Its easy to remove, but is it the better option. I was thinking, that in this case, the resource adapter is like a jdbc driver, you ask it what's its capabilities are. The configuration of the resource adapter is there, then why not add what it supports too. The translator will check for the capability from the Cache (i.e., cache wrapper) and then performs the appropriate type of query. I really think, the function of querying (e.g. by key, lucene or DSL) should be moved into the cache wrapper, so the translator doesn't need to control how its performed. And with the addition of DSL support and the dependencies on google protobuf's, if we don't segment this more, there will be no separation between the translator and resource adapter.

I think that it was put onto the translator since there was no inherent logic in the resource adapter that determined whether searching is supported and all of the dependent logic is in the translator as well. Wouldn't this change be simpler as just removing the rar property?