Directory Studio
  1. Directory Studio
  2. DIRSTUDIO-735

"Copy table" icon in the results page doesn't keep the rank of multivaluate attributes

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.5.3
    • Fix Version/s: None
    • Component/s: studio-ldapbrowser
    • Labels:
      None

      Description

      The "Copy table" icon present in the results page of an ldap search is usefull to export the results by copy/paste.
      The issue is that the values of multivaluate attributes are sorted by alphabetical order (not in the real order in LDAP).
      The rank of the values can be important (like in my case).

      Note that the export function keep the good rank for the multivaluate attibutes; the issue is only about the "Copy table" function

        Activity

        Hide
        Emmanuel Lecharny added a comment -

        One important thing : you should make no assumption about the value order in an attribute. It's not mandatory. Morever, if you use JNDI from Java 5 you will get those values in a different order than if you use JNDI with Java 6...

        I would requalify this issue as a 'New Feature', it's certainly not a bug. I understand that it would be "cool" (TM) to be able to sort the values, but this would be strictly a local (ie, on Studio) operation.

        Show
        Emmanuel Lecharny added a comment - One important thing : you should make no assumption about the value order in an attribute. It's not mandatory. Morever, if you use JNDI from Java 5 you will get those values in a different order than if you use JNDI with Java 6... I would requalify this issue as a 'New Feature', it's certainly not a bug. I understand that it would be "cool" (TM) to be able to sort the values, but this would be strictly a local (ie, on Studio) operation.
        Hide
        Pierre-Arnaud Marcelot added a comment -

        The big problem with this issue is that LDAP RFCs specify that for an entry, "the set of attribute values is unordered".

        RFC2251 - http://www.ietf.org/rfc/rfc2251
        "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."

        RFC4511 - http://www.ietf.org/rfc/rfc4511
        "No two of the attribute values may be equivalent as described by Section 2.2 of [RFC4512]. The set of attribute values is unordered. Implementations MUST NOT rely upon the ordering being repeatable."

        Now, of course, given a particular implementation you could expect to get the attribute values always in the same order, but not necessarily.
        I think ApacheDS does this for example, but I'm not sure it was ever guaranteed or intended.
        This could be particularly difficult when working in an environment with various implementations in place or when switching from one to another.

        That said, I understand that it can be handy sometimes to rely on it.

        We'll see what we could do about it...

        Show
        Pierre-Arnaud Marcelot added a comment - The big problem with this issue is that LDAP RFCs specify that for an entry, "the set of attribute values is unordered". RFC2251 - http://www.ietf.org/rfc/rfc2251 "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." RFC4511 - http://www.ietf.org/rfc/rfc4511 "No two of the attribute values may be equivalent as described by Section 2.2 of [RFC4512] . The set of attribute values is unordered. Implementations MUST NOT rely upon the ordering being repeatable." Now, of course, given a particular implementation you could expect to get the attribute values always in the same order, but not necessarily. I think ApacheDS does this for example, but I'm not sure it was ever guaranteed or intended. This could be particularly difficult when working in an environment with various implementations in place or when switching from one to another. That said, I understand that it can be handy sometimes to rely on it. We'll see what we could do about it...
        Hide
        Pascal Espag. added a comment - - edited

        Thank your for your fast answer, you have right, RFC does not advise to use the values order.

        The "simple" algorythm that you use for your file export (csv, excel, ldif) and the screen display (keep the same order that an ldap search command line) is perfect for me; your choice to do alphabetical sort specially for "copy table" has perhaps a technical explanation, but if you can do the same way it would be great.

        Apache Directory Studio is a great product, and hopefully I can use the "export to excel" to keep the order. I understand it's not a bug, and I will be prudent about the analyze of the order

        Show
        Pascal Espag. added a comment - - edited Thank your for your fast answer, you have right, RFC does not advise to use the values order. The "simple" algorythm that you use for your file export (csv, excel, ldif) and the screen display (keep the same order that an ldap search command line) is perfect for me; your choice to do alphabetical sort specially for "copy table" has perhaps a technical explanation, but if you can do the same way it would be great. Apache Directory Studio is a great product, and hopefully I can use the "export to excel" to keep the order. I understand it's not a bug, and I will be prudent about the analyze of the order

          People

          • Assignee:
            Unassigned
            Reporter:
            Pascal Espag.
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development