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