You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2011/06/16 11:21:55 UTC
Morning thoughts about alias handling...
Hi,
so I slept on the problem, and here are a few thoughts I had this morning :
- first, the alias handling can't be done in the doSimpleSearch() as I
thought, because if we do so, alias dereferencing won't be handled when
using the coreSession. It must be handled by the EntryFilteringCursor.
Remains to see how to implement that there.
- second, we may have some issue when an alias points to a non existing
entry. What will the cursor.next() return in this case ? The alias
exists, so the cursor.next() will move forward, to something that does
not exist (this is a Pierre-Arnaud thought).
- third, we have to fix the reverter, which doe snot handle correctly
alias removal, if the entry which is pointed doe snot exist anymore.
There is a JIRA for that issue.
I'll do my best today to get something done.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Morning thoughts about alias handling...
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
On 16 juin 2011, at 13:14, Emmanuel Lecharny wrote:
> On 6/16/11 1:00 PM, Kiran Ayyagari wrote:
>> On Thu, Jun 16, 2011 at 2:51 PM, Emmanuel Lecharny<el...@gmail.com> wrote:
>>> Hi,
>>>
>>> so I slept on the problem, and here are a few thoughts I had this morning :
>>> - first, the alias handling can't be done in the doSimpleSearch() as I
>>> thought, because if we do so, alias dereferencing won't be handled when
>>> using the coreSession. It must be handled by the EntryFilteringCursor.
>>> Remains to see how to implement that there.
>>> - second, we may have some issue when an alias points to a non existing
>>> entry. What will the cursor.next() return in this case ? The alias exists,
>>> so the cursor.next() will move forward, to something that does not exist
>>> (this is a Pierre-Arnaud thought).
>> hmm, if the aliased entry doesn't exist the cursor shouldn't move forward
>
> Yes, but it's hard to know if the aliased entry exists *before* trying to fetch it...
Indeed, but I think it's mandatory in our case and if we want to maintain the contract between the cursor.next() and cursor.get() methods.
Otherwise it could be broken in some rare situations like the one exposed above.
Regards,
Pierre-Arnaud
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: Morning thoughts about alias handling...
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 6/16/11 1:00 PM, Kiran Ayyagari wrote:
> On Thu, Jun 16, 2011 at 2:51 PM, Emmanuel Lecharny<el...@gmail.com> wrote:
>> Hi,
>>
>> so I slept on the problem, and here are a few thoughts I had this morning :
>> - first, the alias handling can't be done in the doSimpleSearch() as I
>> thought, because if we do so, alias dereferencing won't be handled when
>> using the coreSession. It must be handled by the EntryFilteringCursor.
>> Remains to see how to implement that there.
>> - second, we may have some issue when an alias points to a non existing
>> entry. What will the cursor.next() return in this case ? The alias exists,
>> so the cursor.next() will move forward, to something that does not exist
>> (this is a Pierre-Arnaud thought).
> hmm, if the aliased entry doesn't exist the cursor shouldn't move forward
Yes, but it's hard to know if the aliased entry exists *before* trying
to fetch it...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Morning thoughts about alias handling...
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
On 16 juin 2011, at 13:00, Kiran Ayyagari wrote:
> On Thu, Jun 16, 2011 at 2:51 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
>> Hi,
>>
>> so I slept on the problem, and here are a few thoughts I had this morning :
>> - first, the alias handling can't be done in the doSimpleSearch() as I
>> thought, because if we do so, alias dereferencing won't be handled when
>> using the coreSession. It must be handled by the EntryFilteringCursor.
>> Remains to see how to implement that there.
>> - second, we may have some issue when an alias points to a non existing
>> entry. What will the cursor.next() return in this case ? The alias exists,
>> so the cursor.next() will move forward, to something that does not exist
>> (this is a Pierre-Arnaud thought).
> hmm, if the aliased entry doesn't exist the cursor shouldn't move forward
Yeah, what I meant in our face to face discussion with Emmanuel was that if you're calling the cursor.next() method after all standard entries have already been processed, it should not return true only because the next entry to process is an alias.
It should at least verify that this target entry pointed by the alias really exists.
This is to prevent a situation where the cursor.next() method would return true (based on the fact that we have an alias without checking if the pointed alias entry exists) and, then a call to the cursor.get() method could return <null> (if the pointed alias entry actually does not exist).
I hope it clarifies a little bit.
Regards,
Pierre-Arnaud
>> - third, we have to fix the reverter, which doe snot handle correctly alias
>> removal, if the entry which is pointed doe snot exist anymore. There is a
>> JIRA for that issue.
>>
>> I'll do my best today to get something done.
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>>
>
>
>
> --
> Kiran Ayyagari
Re: Morning thoughts about alias handling...
Posted by Kiran Ayyagari <ka...@apache.org>.
On Thu, Jun 16, 2011 at 2:51 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi,
>
> so I slept on the problem, and here are a few thoughts I had this morning :
> - first, the alias handling can't be done in the doSimpleSearch() as I
> thought, because if we do so, alias dereferencing won't be handled when
> using the coreSession. It must be handled by the EntryFilteringCursor.
> Remains to see how to implement that there.
> - second, we may have some issue when an alias points to a non existing
> entry. What will the cursor.next() return in this case ? The alias exists,
> so the cursor.next() will move forward, to something that does not exist
> (this is a Pierre-Arnaud thought).
hmm, if the aliased entry doesn't exist the cursor shouldn't move forward
> - third, we have to fix the reverter, which doe snot handle correctly alias
> removal, if the entry which is pointed doe snot exist anymore. There is a
> JIRA for that issue.
>
> I'll do my best today to get something done.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Kiran Ayyagari
Re: Morning thoughts about alias handling...
Posted by Emmanuel Lecharny <el...@apache.org>.
On Fri, Jun 17, 2011 at 8:39 PM, Alex Karasulu <ak...@gmail.com> wrote:
> Hiya,
>
> Going totally off memory here from years back. The search engine was
> designed to expand the scope that aliases introduce with their references.
> Meaning the scope expands to new areas if the reference points outside of
> the base of the search: of course this is more complex when considering
> deref modes and where the alias is.
>
> But essentially I was under the impression that dereferencing was not
> handled in higher levels outside of the xdbm search in the partition. Hence
> not in the filters injected into the returned cursor system. Are u
> witnessing the contrary conditions?
>
No, you are right. The current system is leveraging (or at least is supposed
to) the alias indexes.
But it does not work correctly.
I think it would be easier to handle aliases by sending new search requests
in the upper cursor, AFAICT atm.
I'm still analysing the current implementation, so I'm not 100% sure.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Morning thoughts about alias handling...
Posted by Alex Karasulu <ak...@gmail.com>.
Hiya,
Going totally off memory here from years back. The search engine was
designed to expand the scope that aliases introduce with their
references. Meaning the scope expands to new areas if the reference
points outside of the base of the search: of course this is more
complex when considering deref modes and where the alias is.
But essentially I was under the impression that dereferencing was not
handled in higher levels outside of the xdbm search in the partition.
Hence not in the filters injected into the returned cursor system. Are
u witnessing the contrary conditions?
Sent from my iPhone
On Jun 16, 2011, at 12:21 PM, Emmanuel Lecharny <el...@gmail.com>
wrote:
> Hi,
>
> so I slept on the problem, and here are a few thoughts I had this
> morning :
> - first, the alias handling can't be done in the doSimpleSearch() as
> I thought, because if we do so, alias dereferencing won't be handled
> when using the coreSession. It must be handled by the
> EntryFilteringCursor. Remains to see how to implement that there.
> - second, we may have some issue when an alias points to a non
> existing entry. What will the cursor.next() return in this case ?
> The alias exists, so the cursor.next() will move forward, to
> something that does not exist (this is a Pierre-Arnaud thought).
> - third, we have to fix the reverter, which doe snot handle
> correctly alias removal, if the entry which is pointed doe snot
> exist anymore. There is a JIRA for that issue.
>
> I'll do my best today to get something done.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>