jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Date Fri, 11 Sep 2009 13:18:57 GMT

    [ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754119#action_12754119

Marcel Reutegger commented on JCR-2170:

Current state of sandbox branch:

- All tests pass
- Compatibility tests in sandbox/jackrabbit-test-harness now also succeed when upgrading/starting
pre 2.0 repositories with jackrabbit-core 2.0
- Performance impact seems to be negligible. see attached comparison of execution time of
unit and integration tests for jackrabbit-core.


- The persistence manager now simply ignore the definition id read from storage. For simplicity
an empty string is currently written as the definition id when an item is stored. This should
be changed by bumping the serialization version and not storing the definition id at all.

The changes can be reviewed with:
svn diff http://svn.apache.org/repos/asf/jackrabbit/trunk http://svn.apache.org/repos/asf/jackrabbit/sandbox/JCR-2170

Feedback welcome. 

> 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
>         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.

View raw message