On 02/13/2015 07:29 AM, Yoann Gini wrote:
Le 13 févr. 2015 à 11:13, Howard Chu hyc@symas.com a écrit :
This has nothing to do with OpenLDAP. You're talking about Apple's privately hacked version of the code. Whatever they do in their custom attributes with their custom plugins is anybody's guess, but don't expect any Standards documented behavior to cover it.
I was hoping to not see an answer like that. So common in all Open Source communities.
You seems really fast to conclude that’s a problem of an hypothetic Apple hack. The source code used by Apple is available here http://opensource.apple.com/source/OpenLDAP/OpenLDAP-491.1/
Do you see a difference with the official repository who can lead to this problem?
I’m not asking for a « go to hell, it’s an Apple hack » answer.
If I’m asking here, it’s because I’m looking for a real valuable answer. Like for example what kind of mechanism in OpenLDAP source code can lead to this situation. An index or something like that for example.
Maybe it’s linked to an Apple hack, maybe not. In any case the only valuable answer for my question is a troubleshooting procedure for this kind of behavior. Nothing else.
The reason you so often see an answer like this is because people like you want Open Source developers to do work for you for free...
The answer is as Howard said, Apple has modified the code, so pay for a support contract with them and ask them. Or see if they will work for you for free.
Our company has been using OpenLDAP for almost 15 years with billions of transactions and have found the query results to always be utterly deterministic...ie, we have always gotten out exactly what we put in and asked for. Out inconsistencies have always been traced back to either our inconsistent input or queries.
In your particular case, without working for you for free for several hours to answer your question, it looks to me like you are adding an additional query criteria that Apple's code is handling differently based on the existence of the criteria.
For example, if I was querying an "unordered" hash data structure and asking for any single element vs a specific element I would expect similar behavior...with no criteria I get whichever element happens to be first in the hash structure at that time and when I specify a hash key I get the specific element data. But you would have to take the time to research Apple's attribute & code to determine if that is a valid analogy in this case.
Good luck!