[JBoss JIRA] (TEIID-3411) LDAP translator and multi-valued arrays
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3411?page=com.atlassian.jira.plugin... ]
Steven Hawkins reopened TEIID-3411:
-----------------------------------
Reopening to determine if this is needed as is - per more recent comments on the case.
> LDAP translator and multi-valued arrays
> ---------------------------------------
>
> Key: TEIID-3411
> URL: https://issues.jboss.org/browse/TEIID-3411
> Project: Teiid
> Issue Type: Feature Request
> Components: LDAP Connector
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Fix For: 8.7.1.6_2, 8.11
>
>
> The problem is with how multi-valued attribute from the LDAP response is handled. They don't want to have the data mapped to an array or multivalued-concat and then transformed into another table to get the unique values. There is an issue with the translator as it should handle multivalued attribute, by simply creating multiple rows for each value of the multivalued attribute.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (TEIID-3471) unable to consume odata service deployed in teiid
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3471?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3471:
---------------------------------------
Once we get past this, there are other issues. Our metadata for arrayiterate for example maps an object array parameter to List(Edm.Binary) - which is not recognized.
> unable to consume odata service deployed in teiid
> -------------------------------------------------
>
> Key: TEIID-3471
> URL: https://issues.jboss.org/browse/TEIID-3471
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.7
> Reporter: Mark Drilling
> Assignee: Steven Hawkins
> Attachments: deployment-exception.txt, MyVDB-vdb.xml, standalone-snippet.xml
>
>
> I am unable to consume odata service created in teiid.
> Steps to reproduce and files are attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (TEIID-3471) unable to consume odata service deployed in teiid
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3471?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3471:
-------------------------------------
Resteasy library is being very strict about the "Accepts" header. The Olingo library when it defined the "$metadata" service it defined as "application/xml;charset=utf-8". Teiid when issues a $metadata call for metadata load it uses "application/xml" (omits the charset=utf-8), Resteasy while matching the requests it does not like it, it expects EXACTLY same header like "application/xml;charser=utf-8" not even "applicatoin/xml;charset=UTF-8"
I remember, asking this RestEasy forums long time ago to loosen this restriction, but there was no any response at that time. I also believe, if omitted UTF-8 can be default, but never found in XML specification related text exactly describing the issue.
> unable to consume odata service deployed in teiid
> -------------------------------------------------
>
> Key: TEIID-3471
> URL: https://issues.jboss.org/browse/TEIID-3471
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.7
> Reporter: Mark Drilling
> Assignee: Steven Hawkins
> Attachments: deployment-exception.txt, MyVDB-vdb.xml, standalone-snippet.xml
>
>
> I am unable to consume odata service created in teiid.
> Steps to reproduce and files are attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (TEIID-3471) unable to consume odata service deployed in teiid
by Mark Drilling (JIRA)
[ https://issues.jboss.org/browse/TEIID-3471?page=com.atlassian.jira.plugin... ]
Mark Drilling updated TEIID-3471:
---------------------------------
Attachment: deployment-exception.txt
MyVDB-vdb.xml
standalone-snippet.xml
Attached exception, dynamic vdb example and standalone snippet of resource adapter definition.
> unable to consume odata service deployed in teiid
> -------------------------------------------------
>
> Key: TEIID-3471
> URL: https://issues.jboss.org/browse/TEIID-3471
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.7
> Reporter: Mark Drilling
> Assignee: Steven Hawkins
> Attachments: deployment-exception.txt, MyVDB-vdb.xml, standalone-snippet.xml
>
>
> I am unable to consume odata service created in teiid.
> Steps to reproduce and files are attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (TEIID-3429) Provide hooks to interrogate metadata prior to full import
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3429?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3429:
---------------------------------------
> If Designer still has to create it's own connection to all these other data sources, which means maintaining all these other Connection Profiles.... then what's the real point of the Teiid Connection Importer? Wasn't it intended to help remove Designer's reliance on Connection Profiles and custom importers?
I would say there are multiple goals, the primary would be to get rid of connection profiles and get rid of the importer logic. We can easily do the latter.
> Provide hooks to interrogate metadata prior to full import
> -----------------------------------------------------------
>
> Key: TEIID-3429
> URL: https://issues.jboss.org/browse/TEIID-3429
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> To support the Desinger we should offer the ability to interrogate metadata prior to full import.
> Exploring metadata is effectively an entirely different mode of operation with respect to the current metadata processing logic on the Teiid side. Also partial metadata isn't something that would neatly be expressed through DDL - tables without columns, a list of schema names, etc.
> Ways around that would be to expose source procedures for metadata interrogation:
>
> getTableNames - which would probably give both the Teiid name and the name in source and consider the current translator metadata settings
> getProcedureNames
> And importer specific info such as for JDBC getTableTypes, getCatalogNames, getSchemaNames
>
> I'd want to keep it fairly high level though. Getting column or key information I'd expect would be done through the normal full import.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (TEIID-3429) Provide hooks to interrogate metadata prior to full import
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIID-3429?page=com.atlassian.jira.plugin... ]
Barry LaFond commented on TEIID-3429:
-------------------------------------
We could come up with a set of "common" default values for JDBC/Hive/Salesformce import properties in Designer. That would solve maybe the 75% use-case for JDBC-like sources.
If Designer still has to create it's own connection to all these other data sources, which means maintaining all these other Connection Profiles.... then what's the real point of the Teiid Connection Importer? Wasn't it intended to help remove Designer's reliance on Connection Profiles and custom importers?
> Provide hooks to interrogate metadata prior to full import
> -----------------------------------------------------------
>
> Key: TEIID-3429
> URL: https://issues.jboss.org/browse/TEIID-3429
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> To support the Desinger we should offer the ability to interrogate metadata prior to full import.
> Exploring metadata is effectively an entirely different mode of operation with respect to the current metadata processing logic on the Teiid side. Also partial metadata isn't something that would neatly be expressed through DDL - tables without columns, a list of schema names, etc.
> Ways around that would be to expose source procedures for metadata interrogation:
>
> getTableNames - which would probably give both the Teiid name and the name in source and consider the current translator metadata settings
> getProcedureNames
> And importer specific info such as for JDBC getTableTypes, getCatalogNames, getSchemaNames
>
> I'd want to keep it fairly high level though. Getting column or key information I'd expect would be done through the normal full import.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (TEIID-3429) Provide hooks to interrogate metadata prior to full import
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3429?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3429:
---------------------------------------
> There have been a number of complaints about the performance of Designer trying to grab the DDL/Schema in the importer. In some cases just setting tableType == TABLE can drastically improve it.
Thus the question about whether we want to more aggressively set default or make the user fill in more prior to importing.
> These require a conversation with the user to successfully model these sources.
Yes and that would still be the case even with these changes as they would only offer be effective for JDBC, Hive, and Salesforce.
As I see it the approaches are:
1. have Teiid re-expose source metadata as exposed above
2. continue to have Designer interact with a local source Connection, for metadata interrogation purposes, then perform the final import with the server.
> Provide hooks to interrogate metadata prior to full import
> -----------------------------------------------------------
>
> Key: TEIID-3429
> URL: https://issues.jboss.org/browse/TEIID-3429
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> To support the Desinger we should offer the ability to interrogate metadata prior to full import.
> Exploring metadata is effectively an entirely different mode of operation with respect to the current metadata processing logic on the Teiid side. Also partial metadata isn't something that would neatly be expressed through DDL - tables without columns, a list of schema names, etc.
> Ways around that would be to expose source procedures for metadata interrogation:
>
> getTableNames - which would probably give both the Teiid name and the name in source and consider the current translator metadata settings
> getProcedureNames
> And importer specific info such as for JDBC getTableTypes, getCatalogNames, getSchemaNames
>
> I'd want to keep it fairly high level though. Getting column or key information I'd expect would be done through the normal full import.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months