jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: OAK-343 considered harmful?
Date Tue, 27 Nov 2012 14:38:27 GMT


On 27.11.12 14:22, Thomas Mueller wrote:
> Hi,
>
> Currently it is planned to use the commit hook feature to update the
> index. Is the commit hook called before saving?

No, it wouldn't be a commit hook then. The question is, whether the 
indexing code depends on being called on commit only. Otherwise we could 
for example re-use the Observer interface we already have for tracking 
transient changes.

Michael

>
> If it can't be easily supported, maybe a simple per-session map (uuid ->
> path) could be used for temporary nodes, within oak-jcr?
>
> Regards,
> Thomas
>
>
>
> On 11/27/12 3:08 PM, "Michael Dürig" <mduerig@apache.org> wrote:
>
>>
>> Hi,
>>
>> I think we should be able to address this by adding the capability to
>> update the index in transient space already instead of waiting for the
>> commit as Jukka mentioned [1].
>>
>> Alex, Tom, do you think something along these lines would be feasible?
>>
>> Michael
>>
>> [1]
>> https://issues.apache.org/jira/browse/OAK-343?focusedCommentId=13463852&pa
>> ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#commen
>> t-13463852
>>
>> On 27.11.12 13:44, Manfred Baedke wrote:
>>> Hi,
>>>
>>> I'm writing an LdapLoginModule using Angela's ExternalLoginModule
>>> framework. This went very smoothly until I tried it with granite-oak,
>>> when I ran into OAK-343: the UserProvider uses
>>> IdentifierManager.getTree() which doesn't work for unsaved nodes due to
>>> a stale search index.
>>> OAK-343 looks pretty severe to me, though there hasn't been progress for
>>> some time. Are there any plans to fix this in the near future?
>>>
>>> Best regards,
>>> Manfred
>

Mime
View raw message