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 Chetan Mehrotra <ch...@gmail.com> on 2016/07/15 07:47:15 UTC

[proposal] New oak:Resource nodetype as alternative to nt:resource

In most cases where code uses JcrUtils.putFile [1] it leads to
creation of below content structure

+ foo.jpg (nt:file)
   + jcr:content (nt:resource)
       - jcr:data

Due to usage of nt:resource each nt:file node creates a entry in uuid
index as nt:resource is referenceable [2]. So if a system has 1M
nt:file nodes then we would have 1M entries in /oak:index/uuid as in
most cases the files are created via [1] and hence all such files are
referenceable

The nodetype defn for nt:file [3] does not mandate that the
requirement for jcr:content being nt:resource.

So should we register a new oak:Resource nodetype which is same as
nt:resource but not referenceable. This would be similar to
oak:Unstructured.

Also what should we do for [1]. Should we provide an overloaded method
which also accepts a nodetype for jcr:content node as it cannot use
oak:Resource

Chetan Mehrotra
[1] https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/JcrUtils.java#L1062

[2]
[nt:resource] > mix:lastModified, mix:mimeType, mix:referenceable
  primaryitem jcr:data
   - jcr:data (binary) mandatory

[3]

[nt:file] > nt:hierarchyNode
  primaryitem jcr:content
  + jcr:content (nt:base) mandatory

Re: [proposal] New oak:Resource nodetype as alternative to nt:resource

Posted by Angela Schreiber <an...@adobe.com>.

Hi Chetan

Yes... I am not too enthusiastic about changing the default implementation
and have it behave differently on let's say Oak 1.5.7 and previous versions
of Oak and Jackrabbit... that's IMHO breaking backwards compatibility of
an API that is potentially widely used and as such asking for nasty bugs.

We cannot expect that usage nt:resource and thus having a referenceable
node was always an (undesirable) side effect. There might be applications
that used the putFile method _because_ it created nt:resource and which
are relying on the jcr:content node to be referenceable.

So, I am fine either a variant of the simple putFile or the explicit way
as you proposed it... we may even end up with both... i don't have a strong
preference here. 

But changing putFile such as proposed by Justin is IMO not an option.

Kind regards
Angela

On 18/07/16 11:04, "Chetan Mehrotra" <ch...@gmail.com> wrote:

>Thanks for the feedback. Opened OAK-4567 to track the change
>
>
>On Mon, Jul 18, 2016 at 12:14 PM, Angela Schreiber <an...@adobe.com>
>wrote:
>> Additionally or alternatively we could create a separate method (e.g.
>> putOakFile
>> or putOakResource or something explicitly mentioning the
>>non-referenceable
>> nature of the content) that uses 'oak:Resource' and state that it
>>requires
>> the
>> node type to be registered and will fail otherwise... that would be as
>>easy
>> to use as 'putFile', which is IMO important.
>
>@Angela - What about Justin's suggestion later around changing the
>current putFile implementation. Have it use oak:Resource is present
>otherwise fallback to nt:resource. This can lead to compatibility
>issue though as javadoc of putFile says it would use nt:resource
>
>Chetan Mehrotra

Re: [proposal] New oak:Resource nodetype as alternative to nt:resource

Posted by Chetan Mehrotra <ch...@gmail.com>.

Thanks for the feedback. Opened OAK-4567 to track the change

On Mon, Jul 18, 2016 at 12:14 PM, Angela Schreiber <an...@adobe.com> wrote:
> Additionally or alternatively we could create a separate method (e.g.
> putOakFile
> or putOakResource or something explicitly mentioning the non-referenceable
> nature of the content) that uses 'oak:Resource' and state that it requires
> the
> node type to be registered and will fail otherwise... that would be as easy
> to use as 'putFile', which is IMO important.

@Angela - What about Justin's suggestion later around changing the
current putFile implementation. Have it use oak:Resource is present
otherwise fallback to nt:resource. This can lead to compatibility
issue though as javadoc of putFile says it would use nt:resource

Chetan Mehrotra

Re: [proposal] New oak:Resource nodetype as alternative to nt:resource

Posted by Angela Schreiber <an...@adobe.com>.

Hi Chetan

On 15/07/16 09:47, "Chetan Mehrotra" <ch...@gmail.com> wrote:

>In most cases where code uses JcrUtils.putFile [1] it leads to
>creation of below content structure
>
>+ foo.jpg (nt:file)
>   + jcr:content (nt:resource)
>       - jcr:data
>
>Due to usage of nt:resource each nt:file node creates a entry in uuid
>index as nt:resource is referenceable [2]. So if a system has 1M
>nt:file nodes then we would have 1M entries in /oak:index/uuid as in
>most cases the files are created via [1] and hence all such files are
>referenceable
>
>The nodetype defn for nt:file [3] does not mandate that the
>requirement for jcr:content being nt:resource.
>
>So should we register a new oak:Resource nodetype which is same as
>nt:resource but not referenceable. This would be similar to
>oak:Unstructured.

+1

>
>Also what should we do for [1]. Should we provide an overloaded method
>which also accepts a nodetype for jcr:content node as it cannot use
>oak:Resource

Yes, we can do that.

Additionally or alternatively we could create a separate method (e.g.
putOakFile
or putOakResource or something explicitly mentioning the non-referenceable
nature of the content) that uses 'oak:Resource' and state that it requires
the
node type to be registered and will fail otherwise... that would be as easy
to use as 'putFile', which is IMO important.

Also I should explicitly refer to the oak-variant in the javadoc of
'putFile'
and explain the difference (and vice versa).

Kind regards
Angela


>
>Chetan Mehrotra
>[1] 
>https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src
>/main/java/org/apache/jackrabbit/commons/JcrUtils.java#L1062
>
>[2]
>[nt:resource] > mix:lastModified, mix:mimeType, mix:referenceable
>  primaryitem jcr:data
>   - jcr:data (binary) mandatory
>
>[3]
>
>[nt:file] > nt:hierarchyNode
>  primaryitem jcr:content
>  + jcr:content (nt:base) mandatory

Re: [proposal] New oak:Resource nodetype as alternative to nt:resource

Posted by Justin Edelson <ju...@justinedelson.com>.

Could [1] simply use oak:Resource if it was available and nt:resource
otherwise? That would require no client code changes as is IMO a sensible
default.

Regards,
Justin
On Fri, Jul 15, 2016 at 3:47 AM Chetan Mehrotra <ch...@gmail.com>
wrote:

> In most cases where code uses JcrUtils.putFile [1] it leads to
> creation of below content structure
>
> + foo.jpg (nt:file)
>    + jcr:content (nt:resource)
>        - jcr:data
>
> Due to usage of nt:resource each nt:file node creates a entry in uuid
> index as nt:resource is referenceable [2]. So if a system has 1M
> nt:file nodes then we would have 1M entries in /oak:index/uuid as in
> most cases the files are created via [1] and hence all such files are
> referenceable
>
> The nodetype defn for nt:file [3] does not mandate that the
> requirement for jcr:content being nt:resource.
>
> So should we register a new oak:Resource nodetype which is same as
> nt:resource but not referenceable. This would be similar to
> oak:Unstructured.
>
> Also what should we do for [1]. Should we provide an overloaded method
> which also accepts a nodetype for jcr:content node as it cannot use
> oak:Resource
>
> Chetan Mehrotra
> [1]
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/JcrUtils.java#L1062
>
> [2]
> [nt:resource] > mix:lastModified, mix:mimeType, mix:referenceable
>   primaryitem jcr:data
>    - jcr:data (binary) mandatory
>
> [3]
>
> [nt:file] > nt:hierarchyNode
>   primaryitem jcr:content
>   + jcr:content (nt:base) mandatory
>

Re: [proposal] New oak:Resource nodetype as alternative to nt:resource

Posted by Julian Reschke <ju...@gmx.de>.

On 2016-07-15 09:47, Chetan Mehrotra wrote:
> In most cases where code uses JcrUtils.putFile [1] it leads to
> creation of below content structure
>
> + foo.jpg (nt:file)
>    + jcr:content (nt:resource)
>        - jcr:data
>
> Due to usage of nt:resource each nt:file node creates a entry in uuid
> index as nt:resource is referenceable [2]. So if a system has 1M
> nt:file nodes then we would have 1M entries in /oak:index/uuid as in
> most cases the files are created via [1] and hence all such files are
> referenceable
> ...

Another thing we could is to reduce the overhead of indexing the UUIDs 
in the first place. At least for MongoDB and RDBs we could easily let 
the underlying persistence layer do it for us.

Best regards, Julian