More for large multival attrs

We can't persist the sorted flag since the sort order between
DB and attr schema don't necessarily agree

diff --git a/servers/slapd/back-mdb/id2entry.c b/servers/slapd/back-mdb/id2entry.c
index 340d2a85c14675ebc0ebe523f42d67a43159502c..fe1f882732cd35cacc3d14ae087533845d81b9a6 100644 (file)
--- a/servers/slapd/back-mdb/id2entry.c
+++ b/servers/slapd/back-mdb/id2entry.c
@@ -837,6 +837,13 @@ static int mdb_entry_partsize(struct mdb_info *mdb, MDB_txn *txn, Entry *e,
  * attribute's values are already sorted. If the MDB_AT_MULTI bit of the
  * attr index is set, the values are stored separately.
  *
+ * Unfortunately, MDB_AT_MULTI and MDB_AT_SORTED are mutually exclusive;
+ * the DB stores big multi-valued attrs in sorted order but the sorting
+ * is according to the DB order which is not guaranteed to match the
+ * attribute's matching rule ordering. So, drop the sorted flag on big
+ * multi-val attributes, the values will need to be resorted when the
+ * entry is read again.
+ *
  * If the MDB_AT_NVALS bit of numvals is set, the attribute also has
  * normalized values present. (Note - a_numvals is an unsigned int, so this
  * means it's possible to receive an attribute that we can't encode due
@@ -876,10 +883,10 @@ static int mdb_entry_encode(Operation *op, Entry *e, MDB_val *data, Ecount *eh)
                if (!a->a_desc->ad_index)
                        return LDAP_UNDEFINED_TYPE;
                l = mdb->mi_adxs[a->a_desc->ad_index];
-               if (a->a_flags & SLAP_ATTR_SORTED_VALS)
-                       l |= MDB_AT_SORTED;
                if (a->a_flags & SLAP_ATTR_BIG_MULTI)
                        l |= MDB_AT_MULTI;
+               else if (a->a_flags & SLAP_ATTR_SORTED_VALS)
+                       l |= MDB_AT_SORTED;
                *lp++ = l;
                l = a->a_numvals;
                if (a->a_nvals != a->a_vals)