Hi,
>
>Currently I am under the impression that we have no knowledge of what
>*might* break, with varying opinions on the matter. Maybe we should to
>find out what *does* break.
I don't think it's possible to easily find out. Customer code might expect
the current behavior, and might silently brea
On Wed, Oct 12, 2016 at 11:24 AM, Bertrand Delacretaz
wrote:
> On Wed, Oct 12, 2016 at 11:18 AM, Julian Sedding wrote:
>> ...As a remedy for implementations that rely on the current referencable
>> nature, we could provide tooling that automatically adds the
>> "mix:referencable" mixin to existin
On Wed, Oct 12, 2016 at 11:18 AM, Julian Sedding wrote:
> ...As a remedy for implementations that rely on the current referencable
> nature, we could provide tooling that automatically adds the
> "mix:referencable" mixin to existing nt:resource nodes...
Good idea, I suppose this can be done with
I'm with Julian R. on this (as I understand him). We should change the
node-type nt:resource to match the JCR 2.0 spec and deal with the
consequences.
Currently I am under the impression that we have no knowledge of what
*might* break, with varying opinions on the matter. Maybe we should to
find o
The latest proposal was not about making nt:resource unreferenceable,
but silently changing the resource type for a nt:resource child node of
a nt:file node to Oak:Resource.
I just found three other places in Sling where nt:file nodes are created
by hand. So with any other mechanism we have to cha
Hi,
I agree with Julian, I think making nt:resource unreferenceable would
(hardcoding some "magic" in Oak) would lead to hard-to-find bugs and
problems.
> So whatever solution we pick, there is a risk that existing code fails.
Yes. But I think if we create a new nodetype, at least it would be ea
On 2016-10-07 10:56, Carsten Ziegeler wrote:
Julian Reschke wrote
On 2016-10-07 08:04, Carsten Ziegeler wrote:
...
The easiest solution that comes to my mind is:
Whenever a nt:resource child node of a nt:file node is created, it is
silently changed to oak:resource.
Carsten
...
Observation:
Julian Reschke wrote
> On 2016-10-07 08:04, Carsten Ziegeler wrote:
>> ...
>> The easiest solution that comes to my mind is:
>>
>> Whenever a nt:resource child node of a nt:file node is created, it is
>> silently changed to oak:resource.
>>
>> Carsten
>> ...
>
> Observation: that might break code
On 2016-10-07 08:04, Carsten Ziegeler wrote:
...
The easiest solution that comes to my mind is:
Whenever a nt:resource child node of a nt:file node is created, it is
silently changed to oak:resource.
Carsten
...
Observation: that might break code that actually wants a referenceable
node: it
On Fri, Oct 7, 2016 at 11:34 AM, Carsten Ziegeler wrote:
> Whenever a nt:resource child node of a nt:file node is created, it is
> silently changed to oak:resource.
I like this!
This can be done via an Editor which does this transformation upon
addition of new node. Something which can be easily
What about a totally different approach. My main problems with some of
the suggestions are:
a) we have to fix a lot of places (post servlet, webdav, other modules
creating files), creating duplicate code. If this is made configurable,
then its even more of a nightmare.
b) oak:resource is not a nod
On 2016-10-05 11:20, Marcel Reutegger wrote:
Hi,
On 04/10/16 16:02, Julian Reschke wrote:
At least in our DocumentStoreImplementations (Mongo and RDB), making the
UUID something indexed by the storage (so either Mongo or the relational
database) should be relatively cheap (after all, the UUID n
Hi,
On 04/10/16 16:02, Julian Reschke wrote:
At least in our DocumentStoreImplementations (Mongo and RDB), making the
UUID something indexed by the storage (so either Mongo or the relational
database) should be relatively cheap (after all, the UUID never changes
once assigned, right?).
The jcr
> At least in our DocumentStoreImplementations (Mongo and RDB), making the
> UUID something indexed by the storage (so either Mongo or the relational
> database) should be relatively cheap (after all, the UUID never changes once
> assigned, right?). That would eliminate the indexing overhead in Oak
On 2016-10-04 15:58, Thomas Mueller wrote:
Hi,
I still do not understand, why we do not delegate the UUID
generation/lookup to the persistence instead of insisting it to be just
like any other property index...
The UUID _generation_ is not a problem. (I it a bit slow, but scales well
- no iss
Hi,
>I still do not understand, why we do not delegate the UUID
>generation/lookup to the persistence instead of insisting it to be just
>like any other property index...
The UUID _generation_ is not a problem. (I it a bit slow, but scales well
- no issue there). The UUID _lookup_ is not a proble
Hi,
2016-10-04 15:21 GMT+02:00 Julian Reschke :
> On 2016-10-04 08:43, Chetan Mehrotra wrote:
>>
>> <>
>>
>> Hi Team,
>>
>> Sometime back we discussed the requirement for oak:Resource as a non
>> referenceable replacement for nt:resource (OAk-4567). This topic was
>> also discussed on DL [1] and a
On 2016-10-04 08:43, Chetan Mehrotra wrote:
<>
Hi Team,
Sometime back we discussed the requirement for oak:Resource as a non
referenceable replacement for nt:resource (OAk-4567). This topic was
also discussed on DL [1] and at that time it was decided that changing
the defaults (making nt:resour
<>
Hi Team,
Sometime back we discussed the requirement for oak:Resource as a non
referenceable replacement for nt:resource (OAk-4567). This topic was
also discussed on DL [1] and at that time it was decided that changing
the defaults (making nt:resource non referenceable ) is not possible
and hen
19 matches
Mail list logo
