[JBoss JIRA] (TEIID-2994) DDL Option properties not namespaced for salesforce
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIID-2994?page=com.atlassian.jira.plugin... ]
Barry LaFond commented on TEIID-2994:
-------------------------------------
We have the new capability (Designer 8.5) to discover the MEDs available through translator properties via the new Teiid API (Teiid 8.7) . These MED namespaces are defined in those properties. Our preferred way of doing things in the Teiid Connection importer is to match the NS in the DDL OPTIONS() to the NS in the MEDs.
Not having any NS in those OPTIONS(), prevents us from doing so. Our only option would be to fall back on the Translator type during the import and select a hard-coded NS to match it and that seems like a hack/risky way to go.
If there is no NS prefix in the OPTIONS() keys, then how is the DDL going to be tied to a specific Translator type?
Backwards compatibility can be achieved only if a NS is provided on the SF OPTIONS() key values, just like any other.
> DDL Option properties not namespaced for salesforce
> ---------------------------------------------------
>
> Key: TEIID-2994
> URL: https://issues.jboss.org/browse/TEIID-2994
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.7
> Reporter: Mark Drilling
> Assignee: Ramesh Reddy
> Attachments: DDLExtOptionsComparison.txt
>
>
> The Option keys for DDL with saleforce source are not getting namespaced. This is inconsistent with other sources like excel. See attached file - comparison of two tables - Excel source vs Salesforce source. The excel keys are prefixed with a namespace teiid_excel: but the salesforce keys are not.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (TEIID-2993) Adding source table with quoted name results in wrong generated SQL statement
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2993?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2993:
---------------------------------------
> we added auto-double-quoting to the names
Are you referring to quoting to the name in source?
> BTW... querying this works fine
That seems wrong. You've likely included the quotes in the Teiid table name, which is not what you want.
> basically it falls back on NIS if name can't be found
No. We always prefer to use the NIS. Only if the NIS is not set do we attempt to use the Teiid name as the source name.
> Any ideas on how to clean this up?
It looks like there may already be several invalid assumptions afoot. So we'll need some more discovery to determine what needs to be done.
> Adding source table with quoted name results in wrong generated SQL statement
> -----------------------------------------------------------------------------
>
> Key: TEIID-2993
> URL: https://issues.jboss.org/browse/TEIID-2993
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 6.0.0
> Reporter: Paul Richardson
> Assignee: Steven Hawkins
>
> Cloned from TEIIDDES-2152:
> 1) Created source model with simple table named "My.Quoted.Table" (including quotes
> 2) Created simple virtual table and pasted: SELECT * FROM "My.Quoted.Table"
> 3) Parser returned a command resulting in the SQL: SELECT * FROM My.Quoted."Table"
> Parser should be able to handle quoted names properly. In this case the SQL should have been valid as is.
> Confirmed that this does go right back to the Teiid parser. To confirm, the following test was included in
> src/test/java/org/teiid/query/parser/TestParser.java
> {code}
> @Test
> public void testQuotedSQLString() {
> String sql = "SELECT * FROM \"My.Quoted.Table\""; //$NON-NLS-1$
> String expected = "SELECT * FROM \"MY.QUOTED.TABLE\""; //$NON-NLS-1$
> helpTest(sql, expected, null);
> }
> {code}
> Test fails with a comparison error with the parser returning the SQL in item 3 above.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (TEIID-2994) DDL Option properties not namespaced for salesforce
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2994?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2994:
-------------------------------------
AFAIK, this is how it has been done always. The namespace construct was added in the middle, then on we have been following the Designer lead on this. Adding is not issue, but concerned if this will break any backwards compatibility etc.
> DDL Option properties not namespaced for salesforce
> ---------------------------------------------------
>
> Key: TEIID-2994
> URL: https://issues.jboss.org/browse/TEIID-2994
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.7
> Reporter: Mark Drilling
> Assignee: Ramesh Reddy
> Attachments: DDLExtOptionsComparison.txt
>
>
> The Option keys for DDL with saleforce source are not getting namespaced. This is inconsistent with other sources like excel. See attached file - comparison of two tables - Excel source vs Salesforce source. The excel keys are prefixed with a namespace teiid_excel: but the salesforce keys are not.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (TEIID-2993) Adding source table with quoted name results in wrong generated SQL statement
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIID-2993?page=com.atlassian.jira.plugin... ]
Barry LaFond commented on TEIID-2993:
-------------------------------------
Back in 8.3.1 we added the validation check to insure that users d-quoted names with "." delimiter because the Permission target's <resource-name> required D-Quotes because the name assumes a *schema.table.column* path. (see TEIIDDES-1993) Also, since users could opt to define their table names in the JDBC importer via "Use Fully Qualified Names" option, we added auto-double-quoting to the names.
EXAMPLE:
Imported table name = "PARTS_XXX.SUPPLIER_PARTS"
Adding this table to an empty view SQL can result in 2 results
# Drag to T-Diagram >>> SELECT * FROM PartsOracle."""PARTS_XXX"."SUPPLIER_PARTS"""
* BTW... querying this works fine
# Paste SELECT * FROM Parts"PARTS_XXX.SUPPLIER_PARTS" >>> SELECT * FROM PARTS_XXX.SUPPLIER_PARTS (ERROR: Group does not exist: PARTSTEST_VIEWS.PARTSSUPPLIER.SUPPLIER_PARTS)
I can also replace: "PARTSSUPPLIER.SUPPLIER_PARTS" with *PARTSSUPPLIER_SUPPLIER_PARTS* or whatever I want and if the Name In Source is OK then I can query the DB even though our names match, which was my understanding of how Teiid runtimes handles "unknown" names.... basically it falls back on NIS if name can't be found.
So now we have conflicting requirements in Designer for using '.' delimiters in names and inconsistent SQL generated depending on which path you choose in designer.
Any ideas on how to clean this up?
> Adding source table with quoted name results in wrong generated SQL statement
> -----------------------------------------------------------------------------
>
> Key: TEIID-2993
> URL: https://issues.jboss.org/browse/TEIID-2993
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 6.0.0
> Reporter: Paul Richardson
> Assignee: Steven Hawkins
>
> Cloned from TEIIDDES-2152:
> 1) Created source model with simple table named "My.Quoted.Table" (including quotes
> 2) Created simple virtual table and pasted: SELECT * FROM "My.Quoted.Table"
> 3) Parser returned a command resulting in the SQL: SELECT * FROM My.Quoted."Table"
> Parser should be able to handle quoted names properly. In this case the SQL should have been valid as is.
> Confirmed that this does go right back to the Teiid parser. To confirm, the following test was included in
> src/test/java/org/teiid/query/parser/TestParser.java
> {code}
> @Test
> public void testQuotedSQLString() {
> String sql = "SELECT * FROM \"My.Quoted.Table\""; //$NON-NLS-1$
> String expected = "SELECT * FROM \"MY.QUOTED.TABLE\""; //$NON-NLS-1$
> helpTest(sql, expected, null);
> }
> {code}
> Test fails with a comparison error with the parser returning the SQL in item 3 above.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (TEIID-2994) DDL Option properties not namespaced for salesforce
by Mark Drilling (JIRA)
Mark Drilling created TEIID-2994:
------------------------------------
Summary: DDL Option properties not namespaced for salesforce
Key: TEIID-2994
URL: https://issues.jboss.org/browse/TEIID-2994
Project: Teiid
Issue Type: Bug
Components: AdminApi
Affects Versions: 8.7
Reporter: Mark Drilling
Assignee: Ramesh Reddy
Attachments: DDLExtOptionsComparison.txt
The Option keys for DDL with saleforce source are not getting namespaced. This is inconsistent with other sources like excel. See attached file - comparison of two tables - Excel source vs Salesforce source. The excel keys are prefixed with a namespace teiid_excel: but the salesforce keys are not.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (TEIID-2994) DDL Option properties not namespaced for salesforce
by Mark Drilling (JIRA)
[ https://issues.jboss.org/browse/TEIID-2994?page=com.atlassian.jira.plugin... ]
Mark Drilling updated TEIID-2994:
---------------------------------
Attachment: DDLExtOptionsComparison.txt
> DDL Option properties not namespaced for salesforce
> ---------------------------------------------------
>
> Key: TEIID-2994
> URL: https://issues.jboss.org/browse/TEIID-2994
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.7
> Reporter: Mark Drilling
> Assignee: Ramesh Reddy
> Attachments: DDLExtOptionsComparison.txt
>
>
> The Option keys for DDL with saleforce source are not getting namespaced. This is inconsistent with other sources like excel. See attached file - comparison of two tables - Excel source vs Salesforce source. The excel keys are prefixed with a namespace teiid_excel: but the salesforce keys are not.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (TEIID-2989) Support odata batching
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2989?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2989.
-----------------------------------
Resolution: Out of Date
Marking as resolved as this was just a test issue. It looks like batching, as implemented by OData4j works correctly.
> Support odata batching
> ----------------------
>
> Key: TEIID-2989
> URL: https://issues.jboss.org/browse/TEIID-2989
> Project: Teiid
> Issue Type: Enhancement
> Components: OData
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.8
>
>
> We nearly have support for OData batching, but the ODataBatchingProvider is registered as a class and not as an instance. Otherwise it appears that a multipart/mixed post to an entity/$batch will allow for batching in OData4j.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (TEIID-2993) Adding source table with quoted name results in wrong generated SQL statement
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2993?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2993:
----------------------------------
Fix Version/s: (was: 8.8)
(was: 8.7.1)
Affects Version/s: 6.0.0
(was: 7.7.2)
(was: 8.7)
Unmarking the fix version as it's unclear what we would want to do here.
Our output name construct, which is basically for presentational considerations, has been co-opted for the alias generation and is not currently suited at preserving raw parsed content.
> Adding source table with quoted name results in wrong generated SQL statement
> -----------------------------------------------------------------------------
>
> Key: TEIID-2993
> URL: https://issues.jboss.org/browse/TEIID-2993
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 6.0.0
> Reporter: Paul Richardson
> Assignee: Steven Hawkins
>
> Cloned from TEIIDDES-2152:
> 1) Created source model with simple table named "My.Quoted.Table" (including quotes
> 2) Created simple virtual table and pasted: SELECT * FROM "My.Quoted.Table"
> 3) Parser returned a command resulting in the SQL: SELECT * FROM My.Quoted."Table"
> Parser should be able to handle quoted names properly. In this case the SQL should have been valid as is.
> Confirmed that this does go right back to the Teiid parser. To confirm, the following test was included in
> src/test/java/org/teiid/query/parser/TestParser.java
> {code}
> @Test
> public void testQuotedSQLString() {
> String sql = "SELECT * FROM \"My.Quoted.Table\""; //$NON-NLS-1$
> String expected = "SELECT * FROM \"MY.QUOTED.TABLE\""; //$NON-NLS-1$
> helpTest(sql, expected, null);
> }
> {code}
> Test fails with a comparison error with the parser returning the SQL in item 3 above.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (TEIID-2992) MongoDB: Offset clause causes MongoDB to crash
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2992?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-2992.
---------------------------------
Labels: Beta1 (was: )
Fix Version/s: 8.7.1
8.8
Resolution: Done
The translation from query to API language objects were defaulting the limit at INT_MAX during the translation. Added explicit check in the MongoDB query parser to check for INT_MAX and skip setting the value if it matches.
> MongoDB: Offset clause causes MongoDB to crash
> ----------------------------------------------
>
> Key: TEIID-2992
> URL: https://issues.jboss.org/browse/TEIID-2992
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.4.1
> Environment: MongoDB < 2.5.2
> Reporter: Filip Elias
> Assignee: Ramesh Reddy
> Labels: Beta1
> Fix For: 8.7.1, 8.8
>
>
> MongoDB(version < 2.5.2) will crash when offset clause is used in SQL query.
> Althought the bug[1] is in MongoDB (Adding big number into $limit causes Mongodb to shutdown), it is also caused by teiid because it adds max integer into $limit which seems to be unnecessary.
> Sample query:
> {code}
> SELECT INTKEY FROM bqt1.smalla ORDER BY INTKEY OFFSET 45 ROWS
> {code}
> Generated mongo command:
> {code}
> { aggregate: "smalla", pipeline: [ { $project: { c_0: "$INTKEY" } }, { $sort: { c_0: 1 } }, { $skip: 45 }, { $limit: 2147483647 } ] }
> {code}
> [1] https://jira.mongodb.org/browse/SERVER-10136
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months