Re: Perldap Attribute storage order
David J Kernen wrote: > I doubt that ldapsearch (and similarly but in an opposite direction, > ldapmodify) do anything special to maintain order; they just process > what they're given in the order they receive it because that's the > easiest way. That's all I wanted Perldap to do too. Just process them in the order it receives them. I'm pretty sure that Perldap does do that on reading, just not on writing. Unfortunately, Perl hashes don't maintain any order, so for Perldap, it's NOT the easiest way. I guess nobody but me thinks it's worth the trouble to work around that. > I'm also not sure how useful it would be to control the order; I've been > doing ldap programming about eight years and it's never been something > that I wanted to do. Examining access logs and the changelog have always > been sufficient for me, along with the occasional ldif diff. When I'm debugging a problem, I just want to be able to use ldapsearch to examine records and have them displayed in a more reasonable order, ie., the order I stored them in. > Just use the addValue method instead of setValues to add one > attribute/value pair per method call, and then call the update method > after calling addValue. That will do what you want. I think the overhead of adding one attribute at a time would be more than it's worth. I guess the solution for me is to write a replacement for ldapsearch that displays records with the attributes in the order I want to see them. Thanks again for your time. Russ -- Russell D. Wilton E Mail: [EMAIL PROTECTED] Network Services Manager Voice: (403) 329-2525 University of Lethbridge FAX: (403) 382-7108 4401 University Drive Lethbridge, Alberta, CANADA T1K 3M4
Re: Perldap Attribute storage order
David J Kernen wrote: Wrong. Perldap is behaving according to the protocol. (See below.) I agree. Perldap is not required to return the attributes in any particular order. This feature would place perldap in direct violation of the LDAP protocol. Here I disagree with you. As the RFC says, the order of attribute values is implementation-dependent, ie, Perldap can return them in any order it likes. Returning the attributes in the same order they were entered is one possible order and there is no reason Perldap couldn't use that order. To say that this violates the protocol, implies that the ldapmodify and ldapsearch programs distributed with the Netscape LDAP also violate the protocol, since they maintain attribute order. To quote RFC2251 section 4.1.8: Each attribute value is distinct in the set (no duplicates). The order of attribute values within the vals set is undefined and implementation-dependent, and MUST NOT be relied upon. I understand that Perldap is at the mercy of the LDAP directory implementation. The directory is not obliged to return the attributes in the order they were entered and if it doesn't, there is nothing Perldap can do about it. If, however, the LDAP directory does return them in order, as the Netscape LDAP does, it would be nice if Perldap maintained that order. And since the protocol forbids counting on the order or attaching an significance to the order, you're asking for trouble if you start doing so. I fully agree with you here. In my previous post, I indicated that this feature would be nice when scanning LDAP entries by eye. It's easier to find errors if the data comes back in the same order you put it in. But, I certainly wouldn't write a program that depended on that order. When I program, I try to keep in mind the "principle of least astonishment". One application of that principle is that data shouldn't change when you aren't looking at it. When you put data in a file or a database, it's not unreasonable to expect to be able to get it back out again looking the same as it went in. Admittedly, the data can get reordered if you edit the record, but barring edits, it seems to me to be good practice for a database to return records the same way it receives them. The developers of the Netscape LDAP directory would seem to agree with me on this one, since their implementation does maintain the attribute order. And the Perldap developer(s) have gone to considerable effort to maintain the attribute order internal to the perl part of Perldap as well. It just looks to me that they dropped the ball when passing the data to the C API part of Perldap. A fix would be nice, but certainly not necessary, for Perldap to continue to be a very useful package. Russ -- Russell D. Wilton E Mail: [EMAIL PROTECTED] Network Services Manager Voice: (403) 329-2525 University of Lethbridge FAX: (403) 382-7108 4401 University Drive Lethbridge, Alberta, CANADA T1K 3M4
Re: Perldap Attribute storage order
Hi: Thanks for your replies. You both said pretty much the same thing - it can't be done. I trust you will agree that when you create a record with ldapmodify, the attributes are stored in the order you enter them, and when you retrieve the record with ldapsearch, the record is returned with the attributes in the original order. So it's not a limitation of the LDAP protcol, it's just a question of why perldap doesn't do it. I've done some poking around in the perldap code and I think I see where the problem is. The programmer goes to considerable lengths to maintain the attribute ordering in the perl code: defining a 'Mozilla::LDAP::Enty' data type to tie the data storage hash to, having the STORE function maintain the order in the '_oc_order_' array, etc. But it is all for naught, since the Conn->add routine to actually store the record, copies all the attributes into a plain hash to pass them to the C API routines for storage. The attribute ordering gets 'hashed' at this point, since the C 'hash2mod' routine that converts the hash into a list of LDAPmod pointers just extracts them from the hash in the order they are physically stored. It looks to me that the only way to preserve the ordering would be to change the interface between the perl and C routines so that Conn->add could pass the '_oc_order_' array or something similar, to the C routines to specify the desired ordering. This could be an optional parameter which if supplied would specify the ordering and if not, the current algorithm would be used. I realize the ordering is completely immaterial to the operation of the LDAP directory and therefore, this is not a high priority item for perldap development, but it would be a nice feature. When doing program development and debugging, extracting records manually with ldapsearch to see if data is being stored properly, it would be a lot more convenient for visually scanning the attributes if they came back in the same order your stored them. Maybe somebody doing perldap development will implement something like this in a future version - I don't think it would be that difficult. Thanks again for your time. Russ Michelle Wyner wrote: > Russ Wilton wrote: > > > > attributes stored in a particular order? I pass the data to Perldap > > using calls to "entry->setValues" in the order I want the attributes > > stored, but they end up in a different order in the LDAP database, as > > shown by retreiving the entry with ldapsearch. Am I missing something > > here, or is it not possible to control the order? I am running Solaris > > 8, Perl 5.6.0, Perldap 1.4.1 and ldapsdk 4.1. > > Thanks. > > Hi Russ, > > Nope, values of attributes are not guaranteed to be stored in a > particular order. > > -- Michelle -- Russell D. Wilton E Mail: [EMAIL PROTECTED] Network Services Manager Voice: (403) 329-2525 University of Lethbridge FAX: (403) 382-7108 4401 University Drive Lethbridge, Alberta, CANADA T1K 3M4
