[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754078#action_12754078 ]
Marcel Reutegger commented on JCR-2170: --------------------------------------- On sandbox branch: - removed usage of NodeDefId and PropDefId from ItemStates in revision: 813753 and 813757 - the definition ids are now only used to diff node types - NodeDef replaced with QNodeDefinition - PropDef replaced with QPropertyDefinition Direct instantiation of Q*DefinitionImpl should be replaced with Q*DefinitionBuilder, but those are currently located in a CND package, which makes it a bit awkward to use. The restructuring proposed in JCR-2301 will help here as well. > 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.