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.