You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2016/07/20 09:19:56 UTC
Why is nt:resource referencable?
Hi,
OAK-4567 introduces a new oak:Resource nodetype as an alternative to
nt:resource which has mix:referenceable.
I understand the idea of making that node non-referencable for
performance reasons, but why is nt:resource referenceable in the first
place?
builtin_nodetypes.cnd [1] has this definition
[nt:resource] > mix:mimeType, mix:lastModified, mix:referenceable
primaryitem jcr:data
- jcr:data (BINARY) mandatory
but the JCR spec (JSR 283 10 August 2009) only has
[nt:resource] > mix:mimeType, mix:lastModified
primaryitem jcr:data
- jcr:data (BINARY) mandatory
Introducing a new nodetype leaks into applications, removing the
default mix:referenceable mixin on nt:resource would be much simpler
(at the cost of a migration tool probably), and people can always
re-add the mixin if they really need it.
WDYT?
-Bertrand
[1] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/resources/org/apache/jackrabbit/oak/plugins/nodetype/write/builtin_nodetypes.cnd
Re: Why is nt:resource referencable?
Posted by Angela Schreiber <an...@adobe.com>.
Hi Chetan
I would not do that even if it was possible as it will break
every single application that relies on nt:resource to extend
from mix:referenceable... these applications would need to change
their code adding the mixin manually which may lead to follow
up issues, because adding a mixin by specification requires
different privileges than creating a node with just a name where
the primary type (in this case nt:resource) was the applicable node
type selected by the system.
I don't see anything wrong with introducing oak:Resource and let
application developers decide on which variant they prefer.
Kind regards
Angela
On 20/07/16 11:41, "Chetan Mehrotra" <ch...@gmail.com> wrote:
>On Wed, Jul 20, 2016 at 2:49 PM, Bertrand Delacretaz
><bd...@apache.org> wrote:
>> but the JCR spec (JSR 283 10 August 2009) only has
>>
>> [nt:resource] > mix:mimeType, mix:lastModified
>> primaryitem jcr:data
>> - jcr:data (BINARY) mandatory
>
>Thats interesting. Did not knew its not mandated in JCR 2.0. However
>looks like for backward compatibility we need to support it. See [1]
>where this was changed
>
>@Marcel - I did not understood JCR-2170 properly. But any chance we
>can switch to newer version of nt:resource and do not modify existing
>nodes and let the new definition effect/enforced only on new node.
>
>Chetan Mehrotra
>[1]
>https://issues.apache.org/jira/browse/JCR-2170?focusedCommentId=12754941&p
>age=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comme
>nt-12754941
Re: Why is nt:resource referencable?
Posted by Chetan Mehrotra <ch...@gmail.com>.
Thanks for all the details Marcel and Angela. That helps ... so look
like oak:Resource is the way to go
On Wed, Jul 20, 2016 at 6:17 PM, Angela Schreiber <an...@adobe.com> wrote:
> I am pretty sure that there was good
> intention behind the change in nt-definition between JCR 1.0 and
> JCR 2.0... but maybe not fully thought through when it comes to
> backwards compatibility
Digging further it appears this concern was raised but not answered [1]
===
Since referenceable nodes are optional the following changes should be
made (decided at F2F):
nt:resource change to NOT referenceable
mix:simpleVerionable change to NOT referenceable
mix:versionable change to referenceable
nt:frozenNode property jcr:frozenUuid change to NOT mandatory
===
Chetan Mehrotra
[1] https://java.net/jira/browse/JSR_283-428
Re: Why is nt:resource referencable?
Posted by Angela Schreiber <an...@adobe.com>.
Hi Chetan
That would be really troublesome for multiple reasons.
First of all nt:resource doesn't allow for residual properties as
it comes with defined set of property definitions. So, any attempt
to write a jcr:uuid property to such a node will fail.
Second, for other nodes that allow for residual properties (such as
e.g. oak:Unstructured), the declaring node type for such an jcr:uuid
property and thus the property definition itself would change
leading to very nasty problems, when you later try to add
mix:referenceable mixin type.
See e.g. OAK-2164, JCR-2779, OAK-2121, OAK-2246 (and maybe more).
So far our claim has always been that jcr:uuid is a reserved
property that must never be used for any other property than
the autocreated, mandatory, protected property defined by
mix:referenceable.
Really, I don't think that this would be feasible...
and just for the record: I am pretty sure that there was good
intention behind the change in nt-definition between JCR 1.0 and
JCR 2.0... but maybe not fully thought through when it comes to
backwards compatibility and I am sure that we would have changed
it when moving to Jackrabbit 2.x if that had worked.
Kind regards
Angela
On 20/07/16 12:53, "Chetan Mehrotra" <ch...@gmail.com> wrote:
>On Wed, Jul 20, 2016 at 4:04 PM, Marcel Reutegger <mr...@adobe.com>
>wrote:
>> Maybe we would keep the jcr:uuid property on the referenceable node and
>>add
>> the mixin?
>
>What if we do not add any mixin and just have jcr:uuid property
>present. The node would anyway be indexed so search would still work.
>Not sure if API semantics require that nodes lookedup by UUID have to
>be referenceable.
>
>For now I think oak:Resource is safest way. But just exploring other
>options if possible!
>
>
>Chetan Mehrotra
Re: Why is nt:resource referencable?
Posted by Marcel Reutegger <mr...@adobe.com>.
Hi,
On 20/07/16 12:53, Chetan Mehrotra wrote:
> What if we do not add any mixin and just have jcr:uuid property
> present. The node would anyway be indexed so search would still work.
that only works to some degree. there would be no property definition
for the jcr:uuid property and should be considered malformed. Changing
such a node would probably fail later, because the Oak type validator
complains about it.
Regards
Marcel
Re: Why is nt:resource referencable?
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Wed, Jul 20, 2016 at 4:04 PM, Marcel Reutegger <mr...@adobe.com> wrote:
> Maybe we would keep the jcr:uuid property on the referenceable node and add
> the mixin?
What if we do not add any mixin and just have jcr:uuid property
present. The node would anyway be indexed so search would still work.
Not sure if API semantics require that nodes lookedup by UUID have to
be referenceable.
For now I think oak:Resource is safest way. But just exploring other
options if possible!
Chetan Mehrotra
Re: Why is nt:resource referencable?
Posted by Marcel Reutegger <mr...@adobe.com>.
Hi,
On 20/07/16 11:41, Chetan Mehrotra wrote:
> @Marcel - I did not understood JCR-2170 properly. But any chance we
> can switch to newer version of nt:resource and do not modify existing
> nodes and let the new definition effect/enforced only on new node.
node types are not versioned, which means all nodes with a given
jcr:primaryType refer to the same node type. either nt:resource extends
from mix:referenceable or it doesn't. as mentioned already, the issue
is with how to upgrade existing content. if we change nt:resource to
not extend from mix:referenceable anymore, we need an upgrade path.
just removing the jcr:uuid property on those nodes is trivial, but
what if there are nodes referencing them? Maybe we would keep the
jcr:uuid property on the referenceable node and add the mixin?
Then there is the question of backward compatibility for code written
against JCR 1.0 and Jackrabbit 2.x / Oak 1.x behaviour, assuming
nt:resource is always mix:referenceable.
Regards
Marcel
Re: Why is nt:resource referencable?
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Wed, Jul 20, 2016 at 2:49 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> but the JCR spec (JSR 283 10 August 2009) only has
>
> [nt:resource] > mix:mimeType, mix:lastModified
> primaryitem jcr:data
> - jcr:data (BINARY) mandatory
Thats interesting. Did not knew its not mandated in JCR 2.0. However
looks like for backward compatibility we need to support it. See [1]
where this was changed
@Marcel - I did not understood JCR-2170 properly. But any chance we
can switch to newer version of nt:resource and do not modify existing
nodes and let the new definition effect/enforced only on new node.
Chetan Mehrotra
[1] https://issues.apache.org/jira/browse/JCR-2170?focusedCommentId=12754941&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12754941
Re: Why is nt:resource referencable?
Posted by Angela Schreiber <an...@adobe.com>.
Hi Bertrand
It used to be mix:referenceable in JSR170 (i.e. JCR 1.0) and we
kept it for backwards compatibility:
https://docs.adobe.com/content/docs/en/spec/jcr/1.0/6.7.22.9_nt_resource.ht
ml
So, adding oak:Resource sounds the right thing to do here.
Kind regards
Angela
On 20/07/16 11:19, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>Hi,
>
>OAK-4567 introduces a new oak:Resource nodetype as an alternative to
>nt:resource which has mix:referenceable.
>
>I understand the idea of making that node non-referencable for
>performance reasons, but why is nt:resource referenceable in the first
>place?
>
>builtin_nodetypes.cnd [1] has this definition
>
> [nt:resource] > mix:mimeType, mix:lastModified, mix:referenceable
> primaryitem jcr:data
> - jcr:data (BINARY) mandatory
>
>but the JCR spec (JSR 283 10 August 2009) only has
>
> [nt:resource] > mix:mimeType, mix:lastModified
> primaryitem jcr:data
> - jcr:data (BINARY) mandatory
>
>Introducing a new nodetype leaks into applications, removing the
>default mix:referenceable mixin on nt:resource would be much simpler
>(at the cost of a migration tool probably), and people can always
>re-add the mixin if they really need it.
>
>WDYT?
>
>-Bertrand
>
>[1]
>http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/res
>ources/org/apache/jackrabbit/oak/plugins/nodetype/write/builtin_nodetypes.
>cnd