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 Michael Dürig <md...@apache.org> on 2012/10/01 17:46:15 UTC

Re: Going beyond path-based access in MK (Was: Mongo property limit)


On 25.9.12 10:20, Stefan Guggisberg wrote:
> On Mon, Sep 24, 2012 at 2:23 PM, Jukka Zitting <ju...@gmail.com> wrote:
>> Hi,
>>
>>
>> Would it make sense to consider adjusting the MicroKernel interface to
>> allow such optimizations?
>
> IIUC storing the path in every record is an implementation detail of the
> current MongoMK design. i am rather reluctant to make major changes
> to the MicroKernel API at this late stage and based on limitations of a
> specific MK implementation approach.

I'd rather make this change at this early stage if it turns out to be 
necessary than having to fix it when we are in production.

Michael

>
> cheers
> stefan
>
>>
>> BR,
>>
>> Jukka Zitting

Re: Going beyond path-based access in MK (Was: Mongo property limit)

Posted by Mete Atamel <ma...@adobe.com>.
I think we all agree that we need to handle the path limit in MongoMK
sooner rather than later but the open question is whether we can fix this
with or without MicroKernel API changes. My feeling is that we can
probably handle this as a MongoMK implementation detail (i.e. no
MicroKernal API changes) but I haven't spent too much time thinking about
possible solutions yet. Once I do that, I'll be able to comment further.

-Mete

On 10/1/12 6:46 PM, "Michael Dürig" <md...@apache.org> wrote:

>
>
>On 25.9.12 10:20, Stefan Guggisberg wrote:
>> On Mon, Sep 24, 2012 at 2:23 PM, Jukka Zitting
>><ju...@gmail.com> wrote:
>>> Hi,
>>>
>>>
>>> Would it make sense to consider adjusting the MicroKernel interface to
>>> allow such optimizations?
>>
>> IIUC storing the path in every record is an implementation detail of the
>> current MongoMK design. i am rather reluctant to make major changes
>> to the MicroKernel API at this late stage and based on limitations of a
>> specific MK implementation approach.
>
>I'd rather make this change at this early stage if it turns out to be
>necessary than having to fix it when we are in production.
>
>Michael
>
>>
>> cheers
>> stefan
>>
>>>
>>> BR,
>>>
>>> Jukka Zitting