[JBoss JIRA] (TEIID-2327) Add column masking
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2327?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2327:
---------------------------------------
After reviewing oracle and db2 implementations and doing some initial mocking, I'm moving forward with functionality similar to oracle - that is the effect of the mask is applied effectively when the table is accessed and only for select/exec. db2 effectively applies the masking when a value is used in a projected function or after the projection - which means that the grouping, joins, etc. take place on the unmasked values. Not only is this more difficult to implement, but it also easily allows for the definition of masks that fail at runtime (using another column value to mask without that column being available such as in a grouping), and without additional restrictions allow for simplistic determination of masked values.
Several additional row/column enhancements may be needed, such as the ability for views/procedures to turn off the effect of transitive masking/filtering and the ability to turn off the check constraint effect of a source table filter.
> Add column masking
> ------------------
>
> Key: TEIID-2327
> URL: https://issues.jboss.org/browse/TEIID-2327
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.4
>
>
> Support for column masking should be added to data roles. A typical approach would be to only affect the final projected values from user queries and have only one mask applicable at a time.
> A possibly related ability would be to hide columns (much like hidden tables) to our metadata.
--
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
11 years
[JBoss JIRA] (TEIID-2489) Enable the case insensitive use of the translator override properties
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2489?page=com.atlassian.jira.plugin... ]
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
11 years
[JBoss JIRA] (TEIID-2489) Enable the case insensitive use of the translator override properties
by Van Halbert (JIRA)
Van Halbert created TEIID-2489:
----------------------------------
Summary: 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
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
11 years