YOJ 2.8.2 (minor updates)

API Changes

• Deprecate IsolationLevel.SNAPSHOT in favor of IsolationLevel.SNAPSHOT_READ_ONLY

Bugfixes

• Treat most table TTL changes as non-critical schema changes
  Now we allow to:

  • Have an entity with a @TTL annotation, but actual TTL different from TTL in annotation
  • Have an entity without a @TTL annotation but actual TTL set (presumably manually, e.g., to mitigate an incident)

  We still disallow dangerous differences:

  • Have an entity explicitly annotated with @TTL but no actual TTL set (app would expect entity rows to be cleaned up, but they won't be!)

YOJ 2.8.1 (bugfixes in StdTxManager and FilterBuilder)

Bugfixes

• #209: attempts count histogram in StdTxManager was observed on every transaction retry, not only on transaction completion (commit/rollback because of exception/retry failure/etc.). E.g., if you had a transaction commit after 9 attempts, all values from 1..9 will be reported in the histogram, not only 9.
  This was very unintuitive, so we've decided to change this behavior in YOJ 2.8.1.
  The old behavior could potentially alert users of rising attempt count while a problematic transaction was still ongoing, but much better solution is just setting a small transaction retry count (<=10) and, in time-critical scenarios, running the transaction with an explicit GRPC deadline via Context.current().withDeadline[After]().{run|call}(...).
• #217: FilterBuilder.eq(<composite field>)/neq(<composite field>) incorrectly disallowed string-value typed subfields of <composite field>

YOJ 2.8.0 (Schema API Cleanup)

Breaking API Changes

APIs Permanently Removed

• Schema.getName() (EntitySchema.getName() remains)

API Removals Rescheduled to 2.9.0

• InMemoryTable.DbMemory
• InMemoryRepositoryTransaction.getMemory(Class)

API Improvements

• YdbDataCompatibilityChecker supports multi-table entities (can now take a list of TableDescriptors, not entity classes)
• New @Table annotation attribute to require explicit table name specification on every table usage: @Table(explicitDescriptor = true|false)
  • Prohibits calls to EntitySchema.getName() because such an entity has no default table name
  • Requires BaseDb.table(TableDescriptor) instead of BaseDb.table(<entity class>) which implicitly deduces table name from schema
  • Requires new TableDescriptor(<entity class>, "<table name>") instead of TableDescriptor.from(<entity class>) which implicitly deduces table name from schema

YOJ 2.7.6 (bugfix in yoj-aspect)

Bugfixes

• 20fa857 [yoj-aspect] FIX: CallRetryableException used incorrect cause

YOJ 2.7.5 (Update YDB Java SDK)

Dependency Updates

• Update YDB Java SDK: 2.3.24 -> 2.3.29 (and YDB Proto API: 1.7.1 -> 1.7.3)
  Updated YDB Java SDK fixes problems with high memory consumption when reading Topics with highly compressed messages (ydb-platform/ydb-java-sdk#554)

YOJ 2.7.4 (StdTxManager fixes and improvements)

Bugfixes and improvements

• StdTxManager's log transaction ID (tx-id in MDC) was not always unique. tx-* MDC keys were nonexistent when logging out of Tx.defer() and Tx.finally() callbacks
  • Properly increment "log transaction ID" (tx-id in MDC) on transaction run, and not on StdTxManager construction.
    Versions of YOJ prior to 2.6.40 got away with it because a fresh StdTxManager instance was force-created by StdTxManager.tx() (for tx name auto-generation), or StdTxManager.withName() and/or StdTxManager.withLogContext() was explicitly called by the user, incrementing the counter.
  • Do not remove tx-* MDC keys before the transaction exception is logged.
    Previous versions of YOJ relied upon slf4j's MDCCloseable, which uses Java's try-with-resources. This meant that MDCCloseable.close()was called beforecatchandfinallyblocks were entered, and the MDC was already cleared of thetx-*` MDC keys. Now we use our own MDC management mechanism (similar to the one proposed for slf4j 2.1.x), and the MDC is cleared at the right time.

YOJ 2.7.3 (Usability Improvements)

Usability Improvements

• #19: Stricter all-args constructor search for POJOs: Improve error messages
• #192: Improve log messages from TableQueryBuilder

YOJ 2.7.2 (Strict All-Args Constructor Search for POJOs)

Internal Improvements

• #19: Stricter all-args constructor search for POJOs
  • Legacy lenient search strategy still enabled by default
  • Strict search strategy can be enabled by opting into Modern YOJ mappings and practices:
    • StdReflector.enableStrictMode()
    • Automatically called by YqlPrimitiveType.useRecommendedMappingFor(...);

YOJ 2.7.1 (API Compatibility Improvements)

API Compatibility Improvements

• Assign default value for @YojTransactional.noRollbackFor(), otherwise all users are forced to set the value for this

Experimental API Improvements

• #192: Check index and orderBy compatibility on all TableQueryBuilder terminal operations (and not only Entity find(int limit))

YOJ 2.7.0 (API Cleanup)

Breaking API Changes

Breaking - Signature Change

• Require T extends Entity<T> for ListRequest<T> and GenericListResult<T, R>
• @YojTransactional.noRollbackFor: Allow some exceptions that don't cause a rollback

Breaking - APIs Permanently Removed

• new RepositoryCache.Key(Class, Object)
• RepositoryCache.Key.getClazz()
• EntityIdSchema.SORT_ENTITY_BY_ID
• EntityIdSchema.getIdComparator(Class)
• InMemoryQueries.find(StreamSupplier, FilterExpression, OrderExpression, Integer, Long)

API Removal Rescheduled to 2.8.0

• InMemoryTable.DbMemory
• InMemoryRepositoryTransaction.getMemory(Class)

Legacy Behavior Removal Rescheduled to 3.0.0

• EnumSerializer.LENIENT being the default

Dependency Updates

• Update to commons-text 1.10.0->1.14.0 with fix for CVE-2025-48924

Experimental API Improvements

#192: Improved Experimental API for ordering table queries and listings by index

• New naming and new enum type (instead of orderByIndex/unorderedByIndex):
  TableQueryBuilder.index("index name", IndexOrder.{UNORDERED|ASCENDING|DESCENDING});
• New naming (instead of [with]OrderByIndex):
  • ListRequest.withIndex("index name", SortOrder.{ASCENDING|DESCENDING});
  • ListRequest.Builder.index("index name", SortOrder.{ASCENDING|DESCENDING});