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

Jukka Zitting updated JCR-2170:
-------------------------------

    Fix Version/s: 1.6.2

In revision 943301 I backported/reimplemented most of these changes in the 1.6 
branch to fix the problems reported in JCR-2433.

> Remove PropDefId and NodeDefId
> ------------------------------
>
>                 Key: JCR-2170
>                 URL: https://issues.apache.org/jira/browse/JCR-2170
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.0.0
>            Reporter: Tobias Bocanegra
>             Fix For: 1.6.2, 2.0-beta1
>
>         Attachments: image001.png
>
>
> the PropDefIds and NodeDefIds are used to quickly lookup a childnode- or 
> property definition in the nodetype registry (or effective nodetype).
> this is heavily used during reading, when calling Property.getDefinition() 
> usually when checking the isMultiple() flag. and of course while writing when 
> getting the definition for the property or childnode. 
> however, this poses problems when a nodetype is changed that is still used in 
> the content. if a property definition is changed due to an altered nodetype, 
> subsequent accesses to that property result in a "invalid propdefid" warning 
> in the log - but the id is recomputed. this is especially a problem when 
> upgrade jackrabbit from 1.x to 2.0, where some of the builtin nodetypes are 
> defined differently.
> i think that it should be feasible to remove the propdefids and nodedefids 
> and compute the definition on demand. i think this can be implemented without 
> performance loss, when some sort of 'signatures' of the items are computed to 
> quickly find the definitions in the effective node type. furthermore, the 
> most common usecase for using the property definition is probably the 
> isMultiple() check - which is now on the Property interface itself - which 
> does not need a definition lookup at all.
> and last but not least, it saves 8 bytes per item in the persistence layer.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to