[JBoss JIRA] Updated: (TEIID-217) LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-217?page=com.atlassian.jira.plugin.... ]
Steven Hawkins updated TEIID-217:
---------------------------------
Attachment: ldap.patch.txt
Here's a prospective set of code changes to teiid. Do you want the delimiter to be configurable? And is the use of the default value metadata value just because you don't want to introduce an extension model. Is there a chance that this will conflict with a traditional default value for the attribute?
> LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-217
> URL: https://issues.jboss.org/browse/TEIID-217
> Project: Teiid
> Issue Type: Feature Request
> Components: LDAP Connector
> Affects Versions: 6.0.0
> Reporter: Michael Walker
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 7.4
>
> Attachments: ldap.patch.txt, LDAPSyncQueryExecution.java
>
>
> If an attribute appears more than once, we should have some way to return all values. Currently, we only return one value, with no rhyme, reason, or determinism as to which one gets returned. Implementing this is difficult when multiple attributes appear more than once, of course. But a simple example of where this problem rears it's head is in modeling LDAP groups. Groups typically have repeating attributes to represent each member, and it would be nice to query all members of a given group, but impossible to do so with the current logic.
> A sophisticated solution would create a normalized view of a DN, breaking out multi-valued attributes into a separate table that could be joined by a primary key. A simple solution might allow attributes to be flagged as "multi-valued", in which case, they could be maintained in a single denormalized table that represents all values in the DN.
> If we build an importer for LDAP, we should consider how to best handle this issue in the importer design.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Commented: (TEIID-217) LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-217?page=com.atlassian.jira.plugin.... ]
Steven Hawkins commented on TEIID-217:
--------------------------------------
I also see unused logic for pagination - it doesn't look like it matters, but the attached is missing how LDAPConnectorConstants.isSunLDAPServer is defined. Are you providing an additional patch for TEIID-1452?
> LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-217
> URL: https://issues.jboss.org/browse/TEIID-217
> Project: Teiid
> Issue Type: Feature Request
> Components: LDAP Connector
> Affects Versions: 6.0.0
> Reporter: Michael Walker
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 7.4
>
> Attachments: LDAPSyncQueryExecution.java
>
>
> If an attribute appears more than once, we should have some way to return all values. Currently, we only return one value, with no rhyme, reason, or determinism as to which one gets returned. Implementing this is difficult when multiple attributes appear more than once, of course. But a simple example of where this problem rears it's head is in modeling LDAP groups. Groups typically have repeating attributes to represent each member, and it would be nice to query all members of a given group, but impossible to do so with the current logic.
> A sophisticated solution would create a normalized view of a DN, breaking out multi-valued attributes into a separate table that could be joined by a primary key. A simple solution might allow attributes to be flagged as "multi-valued", in which case, they could be maintained in a single denormalized table that represents all values in the DN.
> If we build an importer for LDAP, we should consider how to best handle this issue in the importer design.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Reopened: (TEIID-1439) Adminshell/API - sequence of datasource creation/VDB deployment and queries results in deployment error
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-1439?page=com.atlassian.jira.plugin... ]
Van Halbert reopened TEIID-1439:
--------------------------------
> Adminshell/API - sequence of datasource creation/VDB deployment and queries results in deployment error
> -------------------------------------------------------------------------------------------------------
>
> Key: TEIID-1439
> URL: https://issues.jboss.org/browse/TEIID-1439
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi, Server
> Affects Versions: 7.1.1
> Reporter: Len DiMaggio
> Assignee: Ramesh Reddy
> Priority: Blocker
> Fix For: 7.1.1, 7.3
>
> Attachments: DeployTest.groovy, server.log_DEBUG_deploy, server.log_TRACE_deploy, weather-ds.xml, weather-vdb.xml
>
>
> See attached standalone adminshell/adminAPI test - this is a new problem in ER7.
> A sequence of 2 iterations of: datasource creation/VDB deployment and queries results in this error:
> DEPLOYMENTS IN ERROR:
> Deployment "vfsfile:/jboss/local/51_ER7/jboss-soa-p-5/jboss-as/server/production/deploy/weather-vdb.xml" is in error due to the following reason(s): java.lang.ClassCastException: java.lang.String cannot be cast to org.teiid.dqp.internal.process.SessionAwareCache$CacheID
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Updated: (TEIID-217) LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-217?page=com.atlassian.jira.plugin.... ]
Steven Hawkins updated TEIID-217:
---------------------------------
Fix Version/s: 7.4
putting back in 7.4
> LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-217
> URL: https://issues.jboss.org/browse/TEIID-217
> Project: Teiid
> Issue Type: Feature Request
> Components: LDAP Connector
> Affects Versions: 6.0.0
> Reporter: Michael Walker
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 7.4
>
> Attachments: LDAPSyncQueryExecution.java
>
>
> If an attribute appears more than once, we should have some way to return all values. Currently, we only return one value, with no rhyme, reason, or determinism as to which one gets returned. Implementing this is difficult when multiple attributes appear more than once, of course. But a simple example of where this problem rears it's head is in modeling LDAP groups. Groups typically have repeating attributes to represent each member, and it would be nice to query all members of a given group, but impossible to do so with the current logic.
> A sophisticated solution would create a normalized view of a DN, breaking out multi-valued attributes into a separate table that could be joined by a primary key. A simple solution might allow attributes to be flagged as "multi-valued", in which case, they could be maintained in a single denormalized table that represents all values in the DN.
> If we build an importer for LDAP, we should consider how to best handle this issue in the importer design.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Updated: (TEIID-217) LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result
by Michael Walker (JIRA)
[ https://issues.jboss.org/browse/TEIID-217?page=com.atlassian.jira.plugin.... ]
Michael Walker updated TEIID-217:
---------------------------------
Attachment: LDAPSyncQueryExecution.java
This attached file contains the added code to support multi-valued attributes. This has been tested and deployed to production at a client site.
You should be able to diff this file against the latest in Teiid and add in this functionality.
Documentation will need to be updated to indicate how to identify an attribute as multivalued (see comments).
> LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-217
> URL: https://issues.jboss.org/browse/TEIID-217
> Project: Teiid
> Issue Type: Feature Request
> Components: LDAP Connector
> Affects Versions: 6.0.0
> Reporter: Michael Walker
> Assignee: Michael Walker
> Priority: Minor
> Attachments: LDAPSyncQueryExecution.java
>
>
> If an attribute appears more than once, we should have some way to return all values. Currently, we only return one value, with no rhyme, reason, or determinism as to which one gets returned. Implementing this is difficult when multiple attributes appear more than once, of course. But a simple example of where this problem rears it's head is in modeling LDAP groups. Groups typically have repeating attributes to represent each member, and it would be nice to query all members of a given group, but impossible to do so with the current logic.
> A sophisticated solution would create a normalized view of a DN, breaking out multi-valued attributes into a separate table that could be joined by a primary key. A simple solution might allow attributes to be flagged as "multi-valued", in which case, they could be maintained in a single denormalized table that represents all values in the DN.
> If we build an importer for LDAP, we should consider how to best handle this issue in the importer design.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Assigned: (TEIID-217) LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result
by Michael Walker (JIRA)
[ https://issues.jboss.org/browse/TEIID-217?page=com.atlassian.jira.plugin.... ]
Michael Walker reassigned TEIID-217:
------------------------------------
Assignee: Steven Hawkins (was: Michael Walker)
> LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-217
> URL: https://issues.jboss.org/browse/TEIID-217
> Project: Teiid
> Issue Type: Feature Request
> Components: LDAP Connector
> Affects Versions: 6.0.0
> Reporter: Michael Walker
> Assignee: Steven Hawkins
> Priority: Minor
> Attachments: LDAPSyncQueryExecution.java
>
>
> If an attribute appears more than once, we should have some way to return all values. Currently, we only return one value, with no rhyme, reason, or determinism as to which one gets returned. Implementing this is difficult when multiple attributes appear more than once, of course. But a simple example of where this problem rears it's head is in modeling LDAP groups. Groups typically have repeating attributes to represent each member, and it would be nice to query all members of a given group, but impossible to do so with the current logic.
> A sophisticated solution would create a normalized view of a DN, breaking out multi-valued attributes into a separate table that could be joined by a primary key. A simple solution might allow attributes to be flagged as "multi-valued", in which case, they could be maintained in a single denormalized table that represents all values in the DN.
> If we build an importer for LDAP, we should consider how to best handle this issue in the importer design.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (TEIID-1382) CTC test producing blank VQT errors but Squirrel does produce expected results
by Warren Gibson (JIRA)
CTC test producing blank VQT errors but Squirrel does produce expected results
-------------------------------------------------------------------------------
Key: TEIID-1382
URL: https://jira.jboss.org/browse/TEIID-1382
Project: Teiid
Issue Type: Bug
Components: Integration Tests
Reporter: Warren Gibson
Assignee: Van Halbert
Priority: Minor
4 vqt queries for DB2 97 are producting a blank XML error file.
Mapping S1001=SELECT * FROM VQT.Mapping1 ORDER BY IntKey
Mapping S1002=SELECT VQT.Mapping1.* FROM VQT.Mapping1 ORDER BY IntKey
Mapping S1003=SELECT * FROM VQT.Mapping1 AS X ORDER BY IntKey
Mapping S1004=SELECT X.* FROM VQT.Mapping1 AS X ORDER BY IntKey
An xml error file is being produced but it is completely blank. It should be noted when I attempt to generate new test results they are also blank. The summary text
indicates the problem is related to Lob:
- Mapping1_Queries_Mapping1_S-1001~Unable to read data from the stream: java.io.IOException: Remote java.io.IOException: com.ibm.db2.jcc.am.SqlException: [jcc][10120][11936][3.58.82] Invalid operation: Lob is closed. ERRORCODE=-4470, SQLSTATE=null
- Mapping1_Queries_Mapping1_S-1002~Unable to read data from the stream: java.io.IOException: Remote java.io.IOException: com.ibm.db2.jcc.am.SqlException: [jcc][10120][11936][3.58.82] Invalid operation: Lob is closed. ERRORCODE=-4470, SQLSTATE=null
- Mapping1_Queries_Mapping1_S-1003~Unable to read data from the stream: java.io.IOException: Remote java.io.IOException: com.ibm.db2.jcc.am.SqlException: [jcc][10120][11936][3.58.82] Invalid operation: Lob is closed. ERRORCODE=-4470, SQLSTATE=null
- Mapping1_Queries_Mapping1_S-1004~Unable to read data from the stream: java.io.IOException: Remote java.io.IOException: com.ibm.db2.jcc.am.SqlException: [jcc][10120][11936][3.58.82] Invalid operation: Lob is closed. ERRORCODE=-4470, SQLSTATE=null
When I run the 4 queries in Squirrel I get results and they seem to match the expected results so I think the queries are actually
returning the proper results. Therefore, I am marking this as a "Minor" problem. It appears to be an issue with the query testing framework choking on Lob.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months