Add Int64 (Large Integer) data type support

[JayVDZ]

Summary

JIM currently only supports Int32 (32-bit integers) for numeric attributes via the Number data type. Active Directory and other directory services use Int64 (64-bit integers) for Large Integer attributes like accountExpires, pwdLastSet, lastLogon, etc. These values exceed the Int32 range and are currently silently skipped during import.

Problem

Data Type	Range	Example Use Case
Int32 (Number)	-2.1B to 2.1B	userAccountControl: 512, 514, 66048 ✅
Int64 (Large Integer)	-9.2×10¹⁸ to 9.2×10¹⁸	accountExpires: 133,500,000,000,000,000 ❌

Current Behaviour

In LdapConnectorUtilities.cs, both Integer (omSyntax=2) and Large Integer (omSyntax=65) map to AttributeDataType.Number:

return omSyntax switch
{
    2 or 65 => AttributeDataType.Number,  // Both map to Int32
    // ...
};

When importing Large Integer values, int.TryParse() fails silently:

// Values that overflow Int32 are silently skipped - this is a limitation
// of JIM's current data model which doesn't have a separate Int64 type

Workaround

Expression functions ToFileTime() and FromFileTime() were added to convert between DateTime and FILETIME format, allowing DateTime attributes to be used in the metaverse and converted on export. However, this doesn't solve the general case of Large Integer attributes.

Proposed Solution

Option A: Add Long Data Type (Minimal Change)

Add a new Long data type alongside the existing Number type:

• Number = Int32 (keep existing behaviour)
• Long = Int64 (new)

Pros: Backward compatible, minimal risk
Cons: Two numeric types with similar names

Option B: Rename and Extend (Breaking Change)

Rename the existing type and add the new one with clearer names:

• Integer = Int32 (renamed from Number)
• LargeInteger or Long = Int64 (new)

Pros: Clearer naming, aligns with AD terminology
Cons: Breaking change for existing configurations

Option C: Unified Numeric Type with Internal Promotion

Keep a single Number type but internally store as Int64, with automatic promotion:

• Store all integers as Int64 internally
• Accept and return Int32 for backward compatibility where possible
• Only use full Int64 range when needed

Pros: No schema changes for users, single type to understand
Cons: More complex implementation, potential precision issues

Implementation Scope

Regardless of approach, changes needed:

1. Models

   • AttributeDataType enum - add new value or rename
   • MetaverseObjectAttributeValue - add LongValue property
   • ConnectedSystemObjectAttributeValue - add LongValue property
   • PendingExportAttributeValueChange - add LongValue property
   • ConnectedSystemImportObjectAttribute - add LongValues property

2. Database

   • Migration to add LongValue columns to relevant tables

3. Connectors

   • LdapConnectorUtilities.GetLdapAttributeDataType() - map omSyntax=65 to new type
   • LdapConnectorImport - handle Long values
   • LdapConnectorExport - handle Long values
   • File connector - parse/write Long values

4. Application Layer

   • All servers that handle attribute values
   • Expression evaluator (if needed)
   • Attribute comparison logic

5. UI

   • Schema configuration pages
   • Attribute value display

6. Tests

   • Unit tests for all affected components
   • Integration tests for Large Integer attributes

AD Large Integer Attributes

These AD attributes use Large Integer (FILETIME) format:

• accountExpires - When the account expires (0 or Int64.MaxValue = never)
• pwdLastSet - When password was last set (0 = must change at next logon)
• lastLogon - Last interactive logon time (not replicated between DCs)
• lastLogonTimestamp - Last logon time (replicated, with 9-14 day lag)
• lockoutTime - When account was locked out (0 = not locked)
• badPasswordTime - Last failed password attempt

Decision Needed

Before implementation, decide on:

1. Naming: Keep Number for Int32, or rename to Integer?
2. Approach: Option A, B, or C?
3. Migration: How to handle existing Number attributes if renamed?

Related

• Expression functions ToFileTime() and FromFileTime() provide a workaround for DateTime-based Large Integer attributes
• See LdapConnectorUtilities.cs lines 209-220 for the current limitation comment

[JayVDZ]

Implemented in PR #249 (branch fix/guid-bool-export-support). Added LongNumber data type for Int64/Large Integer values, with full support in LDAP connector, database, and expression functions (ToFileTime/FromFileTime).