[
https://issues.jboss.org/browse/TEIID-2994?page=com.atlassian.jira.plugin...
]
Ramesh Reddy commented on TEIID-2994:
-------------------------------------
If there is no NS prefix in the OPTIONS() keys, then how is the DDL
going to be tied to a specific Translator type?
yes, extension properties and
translator go together for translator. That is why SteveH has been critical of design with
namespaces as it is adding more issues than it is solving.
Backwards compatibility can be achieved only if a NS is provided on
the SF OPTIONS() key values, just like any other.
I am not sure what you mean by
here. Here is my concern, currently translator has for ages has been reading these
properties without a namespace on the property name, if we add it now, if a user gets
their old vdb and deploys into to new runtime, it will fail to recognize those values.
However, there are couple things specific to this translator,
* I am not sure why original author defined these metadata properties, but when I looked
at them in the code they are being used at all. So it does not matter, so I could add the
namespace
* I could add compensating code to look both with name space and without
thus I did not reject the issue, i will fix accordingly. Do we need this also in 8.7.1?
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)