Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <200291396.1245848587560.JavaMail.jira@brutus>
Date: Wed, 24 Jun 2009 06:03:07 -0700 (PDT)
From: "Tobias Bocanegra (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Created: (JCR-2170) Remove PropDefId and NodeDefId
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Remove PropDefId and NodeDefId
------------------------------

                 Key: JCR-2170
                 URL: https://issues.apache.org/jira/browse/JCR-2170
             Project: Jackrabbit Content Repository
          Issue Type: Improvement
          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.