[
https://issues.jboss.org/browse/TEIIDDES-2094?page=com.atlassian.jira.plu...
]
Ramesh Reddy commented on TEIIDDES-2094:
----------------------------------------
Now that we can get Property Definitions from the API... not sure what
to do with that data. I see you are defining these >properties view java @annotation
attributes.
Annotations is way other translator properties have been defined, that seemed to be best
way to add additional metadata that can be discovered programatically. The intention is
to provide the extended metadata properties used by a particular translator.
The application of extension properties to EMF (tags referencing
actual objects) objects is pretty straight forward, but >there also has to be some
mapping between the Teiid property definitions and their target EMF object types.
Teiid does not have EMF objects, the owner objects are from Teiid's metadata API,
which is public API that is been used by Teiid as well as all custom translator
developers. Yes, I suspect that there needs to be some kind of mapping needs to happen
between Teiid Metadata objects and EMF records.
However, without persisting the entire set of property definitions
(either in the model on in the Designer workspace) it'd be >impossible to re-edit a
model and change the extension property values. There has to be a "schema- like-
definition >somewhere (aka MED) that is the frame of reference to make this possible.
This seems like implementation detail, if we need to persist that is fine. There are two
ways to read the extension properties
1) At start-up read all the translators when server connection is made, and store in the
MED registry
2) Read before "Teiid Connection Import", after selecting the translator, but
make MED local to the project set and apply automatically on the imported model.
I think I prefer (2) right now.
So Designer options would be to create another type of MED OR somehow
convert the runtime ext. properties into a
MED.
I am not familiar with internals of Designer's MED framework, I would think it is kind
of combination of both. Need to convert properties into a MED that needs to be applied
only on the source model that being imported and definition can be local.
Seems to me that we're bookkeeping extension properties using 2
methodologies and ... that we're missing something >here in our design(s).
Not really. *.mxd and MED are tooling concepts, Teiid runtime has no knowledge of them.
All Teiid runtime cares is simple name/value pairs on the metadata objects. Granted there
are two usecases here, their use is different
1) Metadata on view models - This *always* requires a code change from Teiid runtime to
take advantage. So we can use tooling's way to define the MED and applied on a model.
This can be communicated between runtime and tooling.
2) Metadata on Custom Source models - This is more dynamic, the user is defining it. Teiid
teams have no control over what they are. When dealing with custom sources, a user must
write a translator and define metadata and figure out how to use it. If we want to make
them use tooling now, either they have to redefine these metadata interms of MED or we
need to figure out a way to re-use properties they defined and provide seamless operation.
I hoping that since MED framework is relatively new and has headless mode, to achieve some
of these tasks.
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
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