[teiid-issues] [JBoss JIRA] (TEIID-2489) Enable the case insensitive use of the translator override properties

[Steven Hawkins (JIRA)]

     [ https://issues.jboss.org/browse/TEIID-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-2489.
-----------------------------------

    Fix Version/s: 8.4
       Resolution: Done


Made two sets of changes.  The first separated out parent/default properties from override translators, which effectively addressed this issue.  The other change was to switch to using a linkedhashmap for the properties to be consistent with VDBMetadataImpl and other metadata objects so that parse/write are nominally order preserving (which at least makes it consistent which property will be used should someone set the same case insensitive key multiple times).
                
> Enable the case insensitive use of the translator override properties 
> ----------------------------------------------------------------------
>
>                 Key: TEIID-2489
>                 URL: https://issues.jboss.org/browse/TEIID-2489
>             Project: Teiid
>          Issue Type: Enhancement
>          Components: Query Engine
>    Affects Versions: 8.4
>            Reporter: Van Halbert
>            Assignee: Steven Hawkins
>             Fix For: 8.4
>
>
> The translator override properties must match exactly the property.  Example:  SupportsNativeQueries must be supportsNativeQueries (starting with lowercase 's') in order for it to work.  
> Conversation:
> It looks like there are several considerations.
> The simplest change would be for AdminObjectImpl to use a string insensitive treemap for properties.
> The variation on that (which is basically what Van is suggesting) if we do not want all admin object properties to be case insensitive would be to allow subclasses to set their own property maps.
> If not one of those, we would at least change the properties to use a LinkedHashMap rather than a HashMap so that the order allows us to determine precedence (but there would be other changes needed as well).
> Generally the strategy of explicitly setting the defaults/parent values on VDBTranslatorMetaData would seem to have some drawbacks.  The primary one is that override translators are essentially modified from their metadata state.  Any write-out of the VDBMetadata from what I can see will then include all of the additional properties.  It seems like we should instead be setting the parent VDBTranslatorMetaData on the child and then resolving the property hierarchy in the TranslatorUtil.

--
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