[
https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754103#action_12754103
]
Marcel Reutegger commented on JCR-2170:
---------------------------------------
On sandbox branch:
- replaced usage of Node/PropertyDefinitionImpl (jackrabbit-core) with classes
from spi-commons
- removed the ones in jackrabbit-core
svn revision: 813788
> 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: 2.0.0
>
>
> 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.
