You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Tobias Bocanegra (JIRA)" <ji...@apache.org> on 2009/06/24 15:03:07 UTC
[jira] Created: (JCR-2170) Remove PropDefId and NodeDefId
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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754954#action_12754954 ]
Stefan Guggisberg commented on JCR-2170:
----------------------------------------
> I think we should change the definition of nt:resource and let it extend from mix:referenceable.
+1
> 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.
[jira] Updated: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger updated JCR-2170:
----------------------------------
Attachment: image001.png
> 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744549#action_12744549 ]
Jukka Zitting commented on JCR-2170:
------------------------------------
+1 to getting rid of the DefIds. IMHO they unnecessarily bind the persisted items to specific node type settings. Resolving the item definitions on demand makes the typing system more flexible.
Also, I'm somewhat scared about the DefIds being essentially just hash codes of the item definitions. What happens when we have a hash collision?
> 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.
[jira] Updated: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger updated JCR-2170:
----------------------------------
Issue Type: Bug (was: Improvement)
IMO this is a bug and needs to be fixed for 2.0, otherwise an upgrade is not possible.
> 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12757849#action_12757849 ]
Marcel Reutegger commented on JCR-2170:
---------------------------------------
There's a regression caused by this change. A NullPointerException is thrown when a node is removed and its parent node had been replaced by a new node with the same UUID in the same save call.
Fixed in revision: 817192
> 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ 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.
Pending:
- 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754122#action_12754122 ]
Jukka Zitting commented on JCR-2170:
------------------------------------
+1 Seems pretty good to me!
> 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.
[jira] Updated: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752411#action_12752411 ]
Marcel Reutegger commented on JCR-2170:
---------------------------------------
Created a development branch in sandbox named JCR-2170.
> 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751046#action_12751046 ]
Marcel Reutegger commented on JCR-2170:
---------------------------------------
As a first step I will replace all Property.getDefinition().isMultiple() with Property.isMultiple(). This will somewhat remove the requirement for Item.getDefinition() to be super fast.
> 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Vidar S. Ramdal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877067#action_12877067 ]
Vidar S. Ramdal commented on JCR-2170:
--------------------------------------
Possible regression: JCR-2652
> 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751063#action_12751063 ]
Marcel Reutegger commented on JCR-2170:
---------------------------------------
Replaced in revision: 811001
> 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754941#action_12754941 ]
Marcel Reutegger commented on JCR-2170:
---------------------------------------
There is an issue with the definition of nt:resource that we have in 2.0. JSR 283 now defines nt:resource as a node type definition that does not inherit from mix:referenceable anymore. in case of an upgrade to jackrabbit 2.0 we still have a jcr:uuid property for each nt:resource node in content. but there's no definition anymore for those properties.
I think we should change the definition of nt:resource and let it extend from mix:referenceable. See also JCR-2303.
WDYT?
> 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745006#action_12745006 ]
Marcel Reutegger commented on JCR-2170:
---------------------------------------
I don't think there is an alternative, I'd even go as far as saying this is not an enhancement but a bug. We have internal code that relies on the fact that those def ids are present in the node type registry. E.g. running the compatibility tests in the sandbox will currently result in NullPointerExceptions when upgrading from a 1.x repository, caused by def ids that have changed (most prominently jcr:isCheckedOut).
> 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723740#action_12723740 ]
Stefan Guggisberg commented on JCR-2170:
----------------------------------------
frankly i don't understand the problem to be solved. If it's just about the warnings in the logs, i'd be against such a major change since the warnings are IMO correct (they indicate a potential repository corruption.
please provide a patch of the suggested change for review and further discussion and please also provide representative profiling figures showing the neutral effect on performance.
> 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754538#action_12754538 ]
Stefan Guggisberg commented on JCR-2170:
----------------------------------------
+1 for the proposed changes
thanks, marcel!
> 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12756718#action_12756718 ]
Marcel Reutegger commented on JCR-2170:
---------------------------------------
Merged sandbox branch into trunk in revision: 816343
> 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744984#action_12744984 ]
Stefan Guggisberg commented on JCR-2170:
----------------------------------------
i'd be +1 for getting rid of the DefIds if the proposed change is more or less performance neutral, otherwise i am -0.5.
> 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.
[jira] Commented: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12756740#action_12756740 ]
Marcel Reutegger commented on JCR-2170:
---------------------------------------
nt:resource now extends from mix:referenceable again. Because of JCR-2303 I had to mark org.apache.jackrabbit.test.api.nodetype.PredefinedNodeTypeTest#testResource as a known issue for jackrabbit-core and jackrabbit-spi2jcr.
svn revision: 816360
> 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.
[jira] Resolved: (JCR-2170) Remove PropDefId and NodeDefId
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger resolved JCR-2170.
-----------------------------------
Resolution: Fixed
> 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.