[ https://issues.jboss.org/browse/TEIIDDES-2094?page=com.atlassian.jira.plu... ] Ramesh Reddy commented on TEIIDDES-2094: ---------------------------------------- Well, then we got more work to do in terms of convincing the other -:) Not really, they are really defined in Teiid Metadata API. Look at "org.teiid.api" package. If you look at supported externalized DDL form you will see extended metadata as "OPTION" properties. "annotations" is *a* way Teiid choose to define dynamic/custom metadata in translators. That does not mean that all the extension metadata needs to be defined as such in Teiid. Most of it is driven by SQL and SQL/MED, then Teiid custom extensions. While it is true that currently there is *no* way query these standard "extension metadata" through Admin API. But this type of "extension metadata" requirement *never* involves a user/customer, it is only involves Teiid and Designer teams. That is you view of it, which I am fine with. * But *do not* assume that a translator developer is also a tooling user and they know how to define MEDs (error-free) in each and every machine. * if the developer does do the MED, how does he share it? does tooling give a "enterprise" wide repository where they can retrieve it from? Then each Designer user specifically loads a MED file, register it, then apply on particular model they are interested in? Would't be *easier* for *user*, if we provide a mechanism this works OOB * How do you suggest the version gap between Designer and Teiid be minimized in terms of supporting new translators. Good example, Teiid put in 4 new translators in 8.7, for testing I/developer can do MED fine. But the end user has to wait however long for the for Designer to pull together next version before they can be supported. This *must* be eliminated. You can not expect a translator developer to first define a MED in Designer and take that file to Teiid translator development, read/parse and use those properties and the supply the MED a part of the translator, when they can simply do this in single line of code. This makes a tight coupling between tooling and Teiid. Do not forget Teiid also has dynamic vdbs to support. If you remember this is same we did with function model in MMx/early Teiid, see what we had to do to fix it. I am trying to show that these are different usecases and *may* need different solutions, I am NOT trying to suggest that you shoehorn these in MED framework, if you think that is not feasible or correct. I understand the designer requirements, as per this JIRA the only use case, I am interested in is what I am saying from usability aspect, what Designer has is not sufficient, it is just a workaround IMO. I am not saying remove MED requirement, that is an implementation detail, the only *REAL* requirement in this usecase is, when Teiid schema import presents its DDL, then *DO NOT THROW AWAY* properties in OPTIONS clause that tooling does not understand. The decision to use some custom property is already been done, just honor it in the tooling, and provide a way to edit the values if needed. How we support it is implementation details, which Admin API is trying to help with. It not trying to redefine how MED are created. We have not seen any use case for version-control as requirement yet Typically this not a normal flow, if user deviates then I am fine with they doing extra work to figuring out and defining what they need, as suggest in beginning. We can document that procedure. That is not true. It does provide isMasked, allowedValues. It does not currently populate default value, but, when the property is "required" it must be defined by the user. If the property is not "required" runtime will automatically will provide a default value. There is no such rule that all properties MUST have a default. That is same paradigm runtime treats all the translator properties. "Locale" support is done by the translator developer. The remaining property is "fixedValue" what does this do? IMO, we once again created this MED framework which is not solving all the previously not foreseen cases such as this. Hypothetically, how would you solve this if there was no MED framework? Then again, what that lacking MED framework, makes this so challenging? Lets start there. -- 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