> 64-bit values for (at least) parent IDs do not get resolved correctly - > only the > lower 32 bits are preserved. This leads up to a crash as it tries to > resolve a > non-existant ID: > > To reproduce: > ldap_entries has a row with an ID of 1,000,000,000 with a parent of > 9,999,999,999 (and > a row 9,999,999,999 for the parent). When back-sql goes to resolve this, the > following shows in the ODBC trace: > > SELECT COUNT(*) FROM > ldap_entry_objclasses,ldap_entries,ldap_static_entries > WHERE ldap_static_entries.id=1410065407 AND > ldap_entries.id=ldap_entry_objclasses.entry_id AND > ldap_entries.keyval=ldap_static_entries.id and ldap_entries.oc_map_id=4 > > (1,410,065,407 = 32-bit rollover of 9,999,999,999).
Currently, IDs are hardcoded as 32-bit unsigned (unsigned long) for internal use. In back-sql, we used the same type. I wonder whether it makes sense to allow to customize them (I think using 64-bit regardless of the arch is not a choice). p.
