[JBoss JIRA] (TEIID-5936) create an s3 file source
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5936?page=com.atlassian.jira.plugi... ]
Steven Hawkins updated TEIID-5936:
----------------------------------
Original Estimate: 1 day
Remaining Estimate: 1 day
Sprint: DV Sprint 66
> create an s3 file source
> -------------------------
>
> Key: TEIID-5936
> URL: https://issues.redhat.com/browse/TEIID-5936
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 15.0
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> The existing s3 support is implemented as a translator / ws source combo. We instead need this to be just a source to allow for translators to utilize it (excel, parquet, avro).
> As an alternative to our existing support we should evaluate utilizing the sdk rather than providing our own processing logic. More than likely this will be a quicker path to things like s3 select support. However ceph seems to lag in s3 support (see TEIID-5935 and no s3 select support) so we'd have to compensate, make the metadata and/or the capabilities specific to the connection type.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (TEIID-5982) Explicit lob closure requires translators to return non-ClobType/BlobType
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5982?page=com.atlassian.jira.plugi... ]
Steven Hawkins updated TEIID-5982:
----------------------------------
Original Estimate: 45 minutes
Remaining Estimate: 45 minutes
> Explicit lob closure requires translators to return non-ClobType/BlobType
> -------------------------------------------------------------------------
>
> Key: TEIID-5982
> URL: https://issues.redhat.com/browse/TEIID-5982
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 15.0
>
> Original Estimate: 45 minutes
> Remaining Estimate: 45 minutes
>
> The logic to trigger explicit closure of source execution only happens if the source returns something that is converted into a blob/clob type. It should either happen for all lobs or made clear in docs / javadocs that clobimpl/blobimpl are required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (TEIID-5982) Explicit lob closure requires translators to return non-ClobType/BlobType
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5982?page=com.atlassian.jira.plugi... ]
Steven Hawkins resolved TEIID-5982.
-----------------------------------
Fix Version/s: 15.0
Resolution: Done
The simpler fix was to change only the file translator - all of the other translators creating blob/clob type would otherwise need to override the exeuctionfactory are lobs usable after close method.
> Explicit lob closure requires translators to return non-ClobType/BlobType
> -------------------------------------------------------------------------
>
> Key: TEIID-5982
> URL: https://issues.redhat.com/browse/TEIID-5982
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 15.0
>
>
> The logic to trigger explicit closure of source execution only happens if the source returns something that is converted into a blob/clob type. It should either happen for all lobs or made clear in docs / javadocs that clobimpl/blobimpl are required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (TEIID-5982) Explicit lob closure requires translators to return non-ClobType/BlobType
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5982?focusedWorklogId=12451707&pag... ]
Steven Hawkins logged work on TEIID-5982:
-----------------------------------------
Author: Steven Hawkins
Created on: 06/Jul/20 3:47 PM
Start Date: 06/Jul/20 3:47 PM
Worklog Time Spent: 45 minutes
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 45 minutes)
Time Spent: 45 minutes
Worklog Id: (was: 12451707)
> Explicit lob closure requires translators to return non-ClobType/BlobType
> -------------------------------------------------------------------------
>
> Key: TEIID-5982
> URL: https://issues.redhat.com/browse/TEIID-5982
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 15.0
>
> Original Estimate: 45 minutes
> Time Spent: 45 minutes
> Remaining Estimate: 0 minutes
>
> The logic to trigger explicit closure of source execution only happens if the source returns something that is converted into a blob/clob type. It should either happen for all lobs or made clear in docs / javadocs that clobimpl/blobimpl are required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (TEIID-5982) Explicit lob closure requires translators to return non-ClobType/BlobType
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5982:
-------------------------------------
Summary: Explicit lob closure requires translators to return non-ClobType/BlobType
Key: TEIID-5982
URL: https://issues.redhat.com/browse/TEIID-5982
Project: Teiid
Issue Type: Bug
Reporter: Steven Hawkins
Assignee: Steven Hawkins
The logic to trigger explicit closure of source execution only happens if the source returns something that is converted into a blob/clob type. It should either happen for all lobs or made clear in docs / javadocs that clobimpl/blobimpl are required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (TEIID-5928) Allow External and Internal materialization of multi-source to fail/update individually
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5928?page=com.atlassian.jira.plugi... ]
Steven Hawkins commented on TEIID-5928:
---------------------------------------
To clarify this was initially implemented for external materialization when the loadnum column is added and is explicit in that it requires two new properties to be set to indicate which view column is the partitioning column and a query to provide the partition values.
This can be expanded to internal materialization, but requires further changes to the systemadmin procedure.
Allowing this form of update without the loadnumber column is problematic with non-transactional sources as you have to delete, then upsert/insert each partition leaving a window where things are invalid. Here again though we could expand the logic and document the risks.
> Allow External and Internal materialization of multi-source to fail/update individually
> ---------------------------------------------------------------------------------------
>
> Key: TEIID-5928
> URL: https://issues.redhat.com/browse/TEIID-5928
> Project: Teiid
> Issue Type: Enhancement
> Components: Common
> Affects Versions: 12.2.2
> Reporter: Rafael Sampaio
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 15.0
>
> Original Estimate: 0 minutes
> Time Spent: 30 minutes
> Remaining Estimate: 0 minutes
>
> Hi, all.
> First of all thanks in advance for your attention, and efforts on such a great product.
> Since I haven't found any docs or examples regarding my current usage (please if this already exists or there's a better way of doing this, disregard this request and advice) here goes my suggestion:
> It would be nice to have a way to gracefully update/fail per source, if a view that has Materialization enabled and target a multi-source source model, because things can get, messy if I have to create a view per source and Materialize each one and only then create a unified (UNION) view.
> Using this approach also obligates me to implement custom insert/update/delete/based on the discriminator column.
> Thanks again.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (TEIIDSB-216) We get error with methadata in Salesforce request
by Renat Eskenin (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-216?page=com.atlassian.jira.plug... ]
Renat Eskenin closed TEIIDSB-216.
---------------------------------
Resolution: Explained
> We get error with methadata in Salesforce request
> -------------------------------------------------
>
> Key: TEIIDSB-216
> URL: https://issues.redhat.com/browse/TEIIDSB-216
> Project: Teiid Spring Boot
> Issue Type: Bug
> Components: datasource
> Reporter: Renat Eskenin
> Priority: Major
>
> We get error from Teiid:
> {code}
> SQL state [50000]; error code [30504]; TEIID30504 salesforce: Unrecognized header: {http://soap.sforce.com/2006/04/metadata}DebuggingInfo; nested exception is org.teiid.jdbc.TeiidSQLException: TEIID30504 salesforce: Unrecognized header: {http://soap.sforce.com/2006/04/metadata}DebuggingInfo
> {code}
> As I think this error faired when we have connection timeout to Salesforce. In other time all works fine.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (TEIIDSB-216) We get error with methadata in Salesforce request
by Renat Eskenin (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-216?page=com.atlassian.jira.plug... ]
Renat Eskenin commented on TEIIDSB-216:
---------------------------------------
We have this problems when SF is down. I checked another SOAP connections. So, this problem occurred when connection exception thrown and SF SOAP client can't get DebugInfo from server. But SF describe this error in bad manner. You can close this task. Tnx.
> We get error with methadata in Salesforce request
> -------------------------------------------------
>
> Key: TEIIDSB-216
> URL: https://issues.redhat.com/browse/TEIIDSB-216
> Project: Teiid Spring Boot
> Issue Type: Bug
> Components: datasource
> Reporter: Renat Eskenin
> Priority: Major
>
> We get error from Teiid:
> {code}
> SQL state [50000]; error code [30504]; TEIID30504 salesforce: Unrecognized header: {http://soap.sforce.com/2006/04/metadata}DebuggingInfo; nested exception is org.teiid.jdbc.TeiidSQLException: TEIID30504 salesforce: Unrecognized header: {http://soap.sforce.com/2006/04/metadata}DebuggingInfo
> {code}
> As I think this error faired when we have connection timeout to Salesforce. In other time all works fine.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months