On 11/19/2014 12:41 PM, Tomas Babej wrote:
> On 11/19/2014 12:24 PM, Martin Kosek wrote:
>> On 11/19/2014 12:03 PM, Tomas Babej wrote:
>>> Hi,
>>> When constructing a parent DN in LDAPSearch, we should always
>>> check that the parent object exists (hence use get_dn_if_exists),
>>> rather than search on unexistant containers (which can happen
>>> with get_dn).
>>> Replaces get_dn calls with get_dn_if_exists in *-find commands
>>> and makes sure proper error message is raised.
>>> https://fedorahosted.org/freeipa/ticket/4659
>> Doesn't it produce extra LDAP search thus making all our search commands
>> slower? Is that what we want? 
> No it does not make all of our LDAP search slower. It only happens for
> the objects that have parent objects, such as idoverrides or dnsrecords.

... and makes them slower.

>> Wouldn't it be better to distinguish between LDAP
>> search with no results and LDAP search with missing parent DN? The reply 
>> looks
>> different, at least in CLI:
> Up to discussion. We would probably need to introduce a new exception,
> like ParentObjectNotFound.
>> # search result
>> search: 4
>> result: 0 Success
>> # search result
>> search: 4
>> result: 32 No such object
>> matchedDN: cn=accounts,dc=mkosek-f20,dc=test
>> Also, I do not think you can just stop using get_dn(), some commands override
>> this call to get more complex searches (like host-find searching for 
>> shortname).
> Look into the get_dn_if_exists, it just wraps around get_dn, so no issue
> here. Any custom behaviour is preserved.

Ah, ok, thanks for info.

> To sum up, I think this is worth changing this behaviour by default,
> ignoring a non-matching value of the parent object is not a correct
> general approach in my opinion.

Well, that's the question. Whether we would leave DS to validate the search
itself or do all the pre-check ourselves. To me, doing just one LDAP search and
processing the error correctly looks better. But I can live even with your
version then, I will leave the framework guardians like Honza or Petr3 to 


Freeipa-devel mailing list

Reply via email to