[JBoss JIRA] (TEIID-2914) Infinispan Connector didn't have the advanced searching option exposed
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-2914?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-2914:
------------------------------------
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.
> Infinispan Connector didn't have the advanced searching option exposed
> ----------------------------------------------------------------------
>
> Key: TEIID-2914
> URL: https://issues.jboss.org/browse/TEIID-2914
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7, 8.7.1
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> The advanced searching option (i.e, lucene searching) that is defined in the .rar was not being picked up in the connector.
> Also, it was incorrectly defined on the translator, because the translator cannot override how the cache is configured.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (TEIID-2914) Infinispan Connector didn't have the advanced searching option exposed
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-2914?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-2914:
------------------------------------
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("{protobuf.objectName}");
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 obtain this info, as the connection has access to this object.
> Infinispan Connector didn't have the advanced searching option exposed
> ----------------------------------------------------------------------
>
> Key: TEIID-2914
> URL: https://issues.jboss.org/browse/TEIID-2914
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7, 8.7.1
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> The advanced searching option (i.e, lucene searching) that is defined in the .rar was not being picked up in the connector.
> Also, it was incorrectly defined on the translator, because the translator cannot override how the cache is configured.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (TEIID-2914) Infinispan Connector didn't have the advanced searching option exposed
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-2914?page=com.atlassian.jira.plugin... ]
Van Halbert edited comment on TEIID-2914 at 4/3/14 8:29 AM:
------------------------------------------------------------
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("{protobuf.objectName}");
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.
was (Author: van.halbert):
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("{protobuf.objectName}");
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 obtain this info, as the connection has access to this object.
> Infinispan Connector didn't have the advanced searching option exposed
> ----------------------------------------------------------------------
>
> Key: TEIID-2914
> URL: https://issues.jboss.org/browse/TEIID-2914
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7, 8.7.1
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> The advanced searching option (i.e, lucene searching) that is defined in the .rar was not being picked up in the connector.
> Also, it was incorrectly defined on the translator, because the translator cannot override how the cache is configured.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (TEIID-2914) Infinispan Connector didn't have the advanced searching option exposed
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2914?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2914:
---------------------------------------
> 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.
> Infinispan Connector didn't have the advanced searching option exposed
> ----------------------------------------------------------------------
>
> Key: TEIID-2914
> URL: https://issues.jboss.org/browse/TEIID-2914
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7, 8.7.1
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> The advanced searching option (i.e, lucene searching) that is defined in the .rar was not being picked up in the connector.
> Also, it was incorrectly defined on the translator, because the translator cannot override how the cache is configured.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (TEIID-2911) Guard against external entity resolving
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2911?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2911:
---------------------------------------
I'll attach the OData patch to this issue as well then. I don't see a place where resteasy is doing the xml entity resolving, but we'll make that config change also.
> Guard against external entity resolving
> ---------------------------------------
>
> Key: TEIID-2911
> URL: https://issues.jboss.org/browse/TEIID-2911
> Project: Teiid
> Issue Type: Bug
> Components: OData, Query Engine
> Affects Versions: 7.7, 8.4
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.4.2, 8.7
>
>
> if applications that expose RESTEasy XML endpoints, add the following snippet to their web.xml file to disable entity expansion in RESTEasy:
> <context-param>
> <param-name>resteasy.document.expand.entity.references</param-name>
> <param-value>false</param-value>
> </context-param>
> Note that this <context-param> setting has precedence over <init-param>, and will override a contrary setting in an <init-param> element.
> However this is not sufficient for OData as OData4j is responsible for parsing the Atom feed. StaxXMLFactoryProvider2 simply creates XMLInputFactories without any options, thus they will perform external entity resolving by default. An issue will need to be opened against OData4j.
> For SQL/XML, the XMLType input factory needs to disable external entity resolving (via experimentation just setting the relevant property doesn't always work, so like other projects we'll set an XMLResolver, which does work).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (TEIID-2916) HIVE2: Teiid didn't translate the SQL correctly for numeric field
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2916?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2916:
----------------------------------
Assignee: (was: Steven Hawkins)
Affects Version/s: 8.8
(was: 8.7)
Component/s: Misc. Connectors
(was: Query Engine)
> HIVE2: Teiid didn't translate the SQL correctly for numeric field
> ------------------------------------------------------------------
>
> Key: TEIID-2916
> URL: https://issues.jboss.org/browse/TEIID-2916
> Project: Teiid
> Issue Type: Sub-task
> Components: Misc. Connectors
> Affects Versions: 8.8
> Environment: HIVE2 with Teiid
> Reporter: Ivan Chan
> Labels: Teiid
>
> Teiid didn't translate the SQL correctly for numeric field. It uses identifier "decimal" in the SQL which is not supported by the driver.
> Original Query:
> select "store_sales",
> "store_state",
> "store_country"
> from "Impala"."sales_new"
> where "store_sales" between 1.5 and 10
> limit 1000
> After Translation (Teiid):
> SELECT g_0.store_sales AS c_0, g_0.store_state AS c_
> 1, g_0.store_country AS c_2 FROM sales_new g_0 WHERE cast(g_0.store_sales AS
> decimal) >= 1.5 AND cast(g_0.store_sales AS decimal) <= 10 LIMIT 1000
> "decimal" is not supported identifier in HIVE driver:
> Encountered: IDENTIFIER
> Expected: BIGINT, BOOLEAN, DATE, DATETIME, REAL, FLOAT, INTEGER, SMALLINT,
> STRING, TIMESTAMP, TINYINT
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (TEIID-2916) HIVE2: Teiid didn't translate the SQL correctly for numeric field
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2916?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2916:
----------------------------------
Parent: TEIID-2647
Workaround Description: (was: Run simple query with Teiid against HIVE2 with contains numeric fields:
select "store_sales",
"store_state",
"store_country"
from "Impala"."sales_new"
where "store_sales" between 1.5 and 10
limit 1000
After Translation (Teiid):
SELECT g_0.store_sales AS c_0, g_0.store_state AS c_
1, g_0.store_country AS c_2 FROM sales_new g_0 WHERE cast(g_0.store_sales AS
decimal) >= 1.5 AND cast(g_0.store_sales AS decimal) <= 10 LIMIT 1000
Encountered: IDENTIFIER
Expected: BIGINT, BOOLEAN, DATE, DATETIME, REAL, FLOAT, INTEGER, SMALLINT,
STRING, TIMESTAMP, TINYINT
CAUSED BY: Exception: Syntax error
at org.apache.hive.jdbc.Utils.verifySuccess(Utils.java:161)
at org.apache.hive.jdbc.Utils.verifySuccessWithInfo(Utils.java:149)
at
org.apache.hive.jdbc.HivePreparedStatement.executeImmediate(HivePreparedStatement.java:187)
at
org.apache.hive.jdbc.HivePreparedStatement.executeQuery(HivePreparedStatement.java:149)
at
org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:123))
Issue Type: Sub-task (was: Bug)
> HIVE2: Teiid didn't translate the SQL correctly for numeric field
> ------------------------------------------------------------------
>
> Key: TEIID-2916
> URL: https://issues.jboss.org/browse/TEIID-2916
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Affects Versions: 8.7
> Environment: HIVE2 with Teiid
> Reporter: Ivan Chan
> Assignee: Steven Hawkins
> Labels: Teiid
>
> Teiid didn't translate the SQL correctly for numeric field. It uses identifier "decimal" in the SQL which is not supported by the driver.
> Original Query:
> select "store_sales",
> "store_state",
> "store_country"
> from "Impala"."sales_new"
> where "store_sales" between 1.5 and 10
> limit 1000
> After Translation (Teiid):
> SELECT g_0.store_sales AS c_0, g_0.store_state AS c_
> 1, g_0.store_country AS c_2 FROM sales_new g_0 WHERE cast(g_0.store_sales AS
> decimal) >= 1.5 AND cast(g_0.store_sales AS decimal) <= 10 LIMIT 1000
> "decimal" is not supported identifier in HIVE driver:
> Encountered: IDENTIFIER
> Expected: BIGINT, BOOLEAN, DATE, DATETIME, REAL, FLOAT, INTEGER, SMALLINT,
> STRING, TIMESTAMP, TINYINT
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months