Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of anchela@adobe.com designates
 64.18.1.218 as permitted sender)
Message-ID: <50B4D818.9020005@adobe.com>
Date: Tue, 27 Nov 2012 16:11:20 +0100
From: Angela Schreiber <anchela@adobe.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: OAK-343 considered harmful?
References: <CCDA8A8C.37D01%mueller@adobe.com>
In-Reply-To: <CCDA8A8C.37D01%mueller@adobe.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

hi tom

IMO that will not work for the case manfred is referring
to as it is operating on the oak-api and not on jcr api.
so -1 for that one.

kind regards
angela

On 11/27/12 3:22 PM, 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?
>
> 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
>