Skip to content

Conversation

@flyingsilverfin
Copy link
Member

Usage and product changes

Implementation

flyingsilverfin and others added 6 commits January 7, 2026 17:02
Upgrade the C# driver to TypeDB 3.0 API with unified entry point and
sessionless transactions:

- Add TypeDB.Driver() unified entry point replacing Drivers.CoreDriver()
- Add IDriver interface with Transaction() methods (no Session layer)
- Add Credentials, DriverOptions, TransactionOptions, QueryOptions classes
- Add ITypeDBTransaction.Query() for direct query execution
- Update TransactionType enum with Schema type for 3.0
- Remove Session layer (ITypeDBSession, TypeDBSession)
- Remove managers (ConceptManager, LogicManager, QueryManager)
- Remove legacy answer types (ConceptMap, ConceptMapGroup, ValueGroup)
- Update DatabaseManager and UserManager for 3.0 native API
- Update test step definitions for 3.0 connection and transaction flow

8 of 14 database behavior tests pass (parallel test has native crash).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
Key changes:
- TypeDBDriver: Store Credentials and DriverOptions references to prevent GC
- TypeDBTransaction: Store TransactionOptions, resolve close/onClose promises
- ConnectionStepsBase: Simplified cleanup to reuse existing driver
- TransactionSteps: Updated BUILD to remove obsolete dependencies

Note: 2/43 transaction tests pass. Tests crash on 3rd driver creation -
likely a native library issue that needs further investigation.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
Changes:
- Add GC.KeepAlive() calls to prevent GC from collecting objects during native calls
- Add guards to IsOpen() and Close() for disposed objects
- Add sleep between test scenarios (matching Java driver workaround)
- Match Java's pattern for driver and transaction close/cleanup

Known issue: Native crash on 3rd consecutive driver creation
- Transaction tests: 2/43 pass before crash
- Database tests: 8/14 pass before crash
- The issue appears to be C# GC finalization timing differing from Java
- Rust driver's async cleanup may race with C# GC finalization
- Further investigation needed at the Rust FFI layer

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
Update BDD test step definitions and BUILD files to support TypeDB 3.0
unified query API patterns. All test-core targets now build successfully.

Key changes:
- Rewrite QuerySteps.cs for unified tx.Query() API
- Add Answer types (IQueryAnswer, IConceptRow, IConceptDocumentIterator)
- Update Concept API with value type checks and accessors
- Remove obsolete Session step references from BUILD files
- Add connection reset database step for test cleanup
- Remove Get and RuleValidation tests (features removed in 3.0)
- Add IncludeQueryStructure to QueryOptions

Tests build and run but crash after 1-2 scenarios due to known SWIG
native memory management issue (documented in ConnectionStepsBase.cs).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
Changes:
- Add 'uniquely identify answer concepts' step with matcher-based approach
  supporting label, key, attr, value, and none identifiers
- Add 'transaction commits; fails with message' step for error checking
- Add 'Then' attribute to transaction opening steps
- Fix 'connection delete database; fails' step to handle both Get and Delete failures
- Add DRIVER_LOCK global mutex in C layer to prevent GC finalization race conditions
- Add transaction_close_sync for synchronous close with callback completion
- Update SWIG bindings for C# director callbacks

Test results:
- Insert tests: 128 passed, 6 skipped
- Define tests: 445/446 passed
- Database/Transaction tests have pre-existing parameterization issues

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
The global mutex was originally added to serialize connection-related
operations for C# GC finalizer thread safety. However, this approach
bottlenecks all language bindings (Java, Python) that share the C layer.

Removing the lock from the C layer because:
1. Tests pass without it, showing no race conditions in practice
2. If C#-specific thread safety is needed, it should be handled in the
   C# layer only, not penalizing other language bindings
3. The Rust driver internally handles thread safety appropriately

Memory management: The key difference is that C# must manually keep references alive due to its concurrent GC/finalizer model, while Java and Python can rely on their runtime's built-in protections.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant