[
https://issues.jboss.org/browse/TEIID-2567?page=com.atlassian.jira.plugin...
]
Steven Hawkins commented on TEIID-2567:
---------------------------------------
which may seem OK, but not from a schema standpoint
That confuses me since it is valid and is exactly the intent. allows are logically
grouped by object type, so it's perfectly natural to reflect that choice in the
schema.
To make this clearer, in an ideal world our permission would basically map to a grant:
grant usage on language javascript
grant select, insert, update on table foo
or for us:
"permission" allows "on" object name
We currently capture name and allows, but not the object type. That's why we have an
odd allows-language to convey "usage" and that the object in question is a
language. See also TEIID-2167
The simple fix/minimal change would to convert <allow-language>
to an attribute and remove the choice.
However that is not consistent with the other allows. Either they can all be elements, or
all be attributes.
I wouldn't try to be backward compatible in this case.
Backwards compatibility is a concern beyond just Designer usage.
issues with permission element in vdb-deployer.xsd contains
problematic choice node
-----------------------------------------------------------------------------------
Key: TEIID-2567
URL:
https://issues.jboss.org/browse/TEIID-2567
Project: Teiid
Issue Type: Task
Affects Versions: 8.4
Reporter: Barry LaFond
Assignee: Steven Hawkins
Fix For: 8.4.1
Having a lot of trouble trying to tweak our JaxB VDB element classes to accommodate the
permission's choice node which contains a <sequence> and an <element>.
This structure is basically impossible to unmarshall using JAXB annotations (i.e.
@XmlElements(value= {}) )
Would clean things up to convert the <allow-language> element to an attribute:
<xs:attribute name="allow-language" type="xs:boolean"/> and
place it on the <permission> element AND remove the <choice> node entirely
--
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