directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@apache.org>
Subject Re: Search result in LDAP API
Date Thu, 28 Apr 2011 14:47:44 GMT
On 4/28/11 4:32 PM, Stefan Seelmann wrote:
>>> b) Convenience methods:  higher-level objects (Dn, Rdn, Strings) are
>>> passed and returned. Examples
>>>     void modify(String dn, Modification... modifications)
>>>     void rename (Dn entryDn, Rdn newRdn)
>>>     Cursor<Entry>    search( Dn baseDn, String filter, SearchScope scope,
>>> String... attributes )
>>>    ->    those methods throw an LdapException in case of an error that
>>> contains the LDAP error code and message.
>> We already have those convenient methods.
> Yes, but they return a XyzResponse (except for the search) and the
> user needs to check the response object to see if the operation was
> successful or not (please correct me if I'm wrong). I think that is
> not what 99% of the users expect.
Ahhh, right I see your point. Throwing an exception in case we had an 
error is way better in these case, sure.
> So my idea of the "high-level" methods" is
> - they take high-level objects as arguments
> - the return type is void (for bind, unbind, add, modify, moddn,
> delete, abandon), boolean (for compare), Cursor<Entry>  (for search),
> not sure about extended
> - they throw an LdapException (or an appropriate sub-type) in case the
> result code is not 0
Makes perfect sense.

> - we should add support for referral handling and search continuation
> (skip, chase, throw exception), not only for search, but also for the
> write methods, but that could be done later
Yeah, it can be done later.
> And the "low-level" methods:
> - take XyzRequest objects as single argument
> - they return an XyzResponse object (for bind, unbind, add, modify,
> moddn, delete, abandon, compare, extended) or a SearchCursor (for
> search)
> - the respose objects must be inspected to find out if the operation
> was sucessful or not, or if there was an referral/search continuation
>
> So for the existing search() method that would mean:
>
> SearchCursor search(SearchRequest searchRequest)
> ->  remains as is
>
> Cursor<Entry>  search(Dn baseDn, String filter, SearchScope scope,
> String... attributes)
> Cursor<Entry>  search(String baseDn, String filter, SearchScope scope,
> String... attributes)
> ->  return value changed, additional overloads to specify referral
> handling may be needed

> I just think a high-level and low-level API is required and try to
> find a consistent rule.

Ok, fine. If everybody agree, we can start refactoring the existing API 
to provide such methods for 1.0.0-M4. Should not be complex.



-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message