[
https://issues.jboss.org/browse/TEIIDDES-2094?page=com.atlassian.jira.plu...
]
Barry LaFond commented on TEIIDDES-2094:
----------------------------------------
I don't see any difference in your 2 use-cases. It's obvious that extension
properties on view models requires MEDs since there are no corresponding
"annotations" in the Teiid Runtime. Source models, by their nature, are tied to
translators which do have coded annotations that are used to define the extended
properties. When dealing with custom translators, users must write the translator and
probably use tooling to write that translator. To me, it seems more intuitive to require
the user to define their Extension properties in the form of a schema (aka MED file) . We
happen to have tooling that can help users create error-free MEDs but the
format/definition is pretty straight forward and can be edited by hand if tooling is an
issue.
I think the biggest issue I have is that we now have a disconnect between design-time and
runtime extension metadata.
* Extending our metamodels has always been an available feature in Designer, whether the
old EMF-based extension model or the new MXD (MED) framework.
* Our MED use-cases/requirements included providing a means to :
** define and model new relational properties that the runtime supported (built-in MEDs)
** allow users to add design-time only extension properties (not added to indexed VDB
metadata)
** allow users to add runtime extension properties required by custom translators
** allow users to version-control their MED files (including validation to warn users of
conflicting or out of date versions applied to models)
This jira is pushing for Designer to:
* remove the requirement for MEDs being used for custom translators
* make it much harder to present any sense of version-control/validation for the user in
the tooling since there doesn't appear to be any info coming through the API to make
that available
* force the user to extract and register the MED definition from a source model if they
wish to create a source model from scratch for that same data source/translator
Note that *@ExtensionMetadataProperty* annotation only supports: *applicable Object
type(s), display name, description, isRequired*
MED properties also support the following methods which is needed by the UI:
* *getDefaultValue()*
* *isMasked()*
* *allowedValues()*
* *fixedValue()*
* *Locale support for Display names and Descriptions*
Because of this missing data, the conversion of the runtime property definition into a
design-time property definition will be incomplete. Designer can infer that a type
Boolean will mean true/false, but a String property with specific "allowed
values" will be treated as a generic editable string value. Because all MED
properties have a "default" value, only non-default values are actually
indexed.
So still not sure on how to satisfy both the support for runtime dynamic extension
metadata and make it useful in design-time and clear to the user what is going on.
Support for dynamic extension metadata
---------------------------------------
Key: TEIIDDES-2094
URL:
https://issues.jboss.org/browse/TEIIDDES-2094
Project: Teiid Designer
Issue Type: Enhancement
Components: Import/Export
Reporter: Ramesh Reddy
Assignee: Paul Richardson
Priority: Critical
Currently when Teiid core implements a new translator or customer/user implements a
custom translator that has extension metadata, before they can use the translator in
Designer to do some modeling, they need to define MED and register it.
With completion of TEIID-2904, in Teiid 8.7, a Admin api method can be used to
interrogate the extension metadata properties defined for a translator.
Currently if user uses Teiid Connection importer with any new translator, it ignores all
the extension metadata properties and removes them from the returned DDL that Designer did
not recognize. That is really bad for custom connectors, because the VDB will not work
properly once it is deployed back to Teiid Server.
I propose to devise a way to generate a dynamic MED for the purposes of current metadata
import of the source and use it during the import and not ignore those extension metadata
properties.
Depending upon implementation detail, we can also read the translators and their
extension metadata support during the initial connection time and create all the required
MEDs and register them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira