Hi guys,
yesterday, as I started to write the doc about the Search Operation, I
faced some issue. Let me explain.
When you do a simple search, you get back a cursor :
SearchCursor cursor = connection.search( "ou=system",
"(objectclass=*)", SearchScope.ONELEVEL );
The SearchCursor extends Cursor<Response>.
That means you get some Response when you do a search, so you have to
write such code to get back the entries :
while ( cursor.next() )
{
Entry entry = ((SearchResultEntry)(cursor.get())).getEntry();
which is just horrible.
The reason is that the search can return three kinds of responses :
- normal entries
- search result done
- and referrals
We can deal with the searchResultDone (and we do, you can call a
cursor.getSearchResultDone() when you quit the loop), but the referral
handling is a bit more special.
We have many options to clean up the API here :
- first, we can consider that a cursor.get() will always return an entry
(or a SearchResultEntry). In this case, if the next result is a
referral, we have two cases. The first one, if the users have asked the
API to chase referrals, he will get back an entry, and we are fine. The
other case is when we don't chase referrals, and then we can just throw
a ReferralException, up to the client to catch this exception
- second, we can expect the user to check the result type before
grabbing it. If it's a SearchResultEntry, then do a cursor.getEntry(),
otherwise do a cursor.getReferral().
- third, we can cumulate all the referrals and ask the user to look on
the cursor a second time to deal with referral. We would have to store
those referrals internally to the cursor, and add a nextReferral() method.
I personally find the first solution the least painful for our users. In
any case, we have to do two things :
- change the current API
- implement the Referral chasing in the API
So, now, wdyt ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
