You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Konrad Windszus (JIRA)" <ji...@apache.org> on 2017/03/02 09:04:50 UTC

[jira] [Updated] (SLING-6588) More granularly invalidate the cached ValidationModels

     [ https://issues.apache.org/jira/browse/SLING-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Konrad Windszus updated SLING-6588:
-----------------------------------
    Description: 
Currently {{ValidationModelProviders}} are asked once for validation models for a specific resource type. The result is cached, which may be invalidated as a whole by the {{ValidationModelProvider}} as well. 
While this works, it always requires a full cache invalidation whenever a new model come into play. Consider the following use case:
# Only one model for resource type {{a}} is available with {{applicablePath}} = {{/content}}
# The model is retrieved from the {{ValidationModelProvider}} for a validation of a resource below {{/content/test/c}}
# A new model for resource type {{a}} becomes available with {{applicablePath}} = {{/content/test}}
That new model should take precedence because its applicable path is more specific. This would only work if between 2. and 3. the cache is fully invalidated.

The new model is actually never leveraged unless the full cache is invalidated in between.

  was:
Currently {{ValidationModelProvider}}s are asked once for validation models for a specific resource type. The result is cached, which may be invalidated as a whole by the {{ValidationModelProvider}} as well. 
While this works, it always requires a full cache invalidation whenever a new model come into play. Consider the following use case:
# Only one model for resource type {{a}} is available with {{applicablePath}} = {{/content}}
# The model is retrieved from the {{ValidationModelProvider}} for a validation of a resource below {{/content/test/c}}
# A new model for resource type {{a}} becomes available with {{applicablePath}} = {{/content/test}}
That new model should take precedence because its applicable path is more specific. This would only work if between 2. and 3. the cache is fully invalidated.

The new model is actually never leveraged unless the full cache is invalidated in between.


> More granularly invalidate the cached ValidationModels
> ------------------------------------------------------
>
>                 Key: SLING-6588
>                 URL: https://issues.apache.org/jira/browse/SLING-6588
>             Project: Sling
>          Issue Type: Improvement
>          Components: Validation
>    Affects Versions: Validation 1.0.0
>            Reporter: Konrad Windszus
>
> Currently {{ValidationModelProviders}} are asked once for validation models for a specific resource type. The result is cached, which may be invalidated as a whole by the {{ValidationModelProvider}} as well. 
> While this works, it always requires a full cache invalidation whenever a new model come into play. Consider the following use case:
> # Only one model for resource type {{a}} is available with {{applicablePath}} = {{/content}}
> # The model is retrieved from the {{ValidationModelProvider}} for a validation of a resource below {{/content/test/c}}
> # A new model for resource type {{a}} becomes available with {{applicablePath}} = {{/content/test}}
> That new model should take precedence because its applicable path is more specific. This would only work if between 2. and 3. the cache is fully invalidated.
> The new model is actually never leveraged unless the full cache is invalidated in between.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)