YOJ 2.6.16 (API improvements)
Key changes ( ❌ denotes breaking changes )
- ➕
YdbTable
now exposes itsQueryExecutor
to subclasses via aprotected getExecutor()
method, and adds apublic getSchema()
method for getting entity schema used for mapping the rows of this table. This makes custom tables with custom queries a little less quirky (but this is still far from an official way of creating custom statements; that will be explored in #43). - ➕ New
@InternalApi
annotation that clearly specifies which publicly visible parts of YOJ API (interfaces, classes, methods, fields, constants, and so on) are implementation details exposed for cross-package and cross-module usage. - ❌
Table
interface methodfind(Set<ID>)
is now required. Direct implementors ofTable
must implement this new method (either by delegating to anotherTable
or by using the internalTableQueryImpl
utility). Those who extendedAbstractDelegatingTable
don't need to do anything. - ❌
Table
interface has dropped thegetFirstLevelCache()
method. There is no replacement.- Direct implementors of
Table
should just delete their implementation ofgetFirstLevelCache()
. - Users of
Table.getFirstLevelCache()
should do one of the following:- Reconsider their usage of Internal API.
- If the usage cannot be eliminated, obtain a
FirstLevelCache
instance by getting it from currentRepositoryTransaction
'sTransactionLocal
:First-level cache can only be used if you have avar tx = Tx.Current.get(); var repositoryTransaction = tx.getRepositoryTransaction(); var transactionLocal = repositoryTransaction.getTransactionLocal(); var cache = transactionLocal.firstLevelCache(<table descriptor>);
RepositoryTransaction
instance or can obtain it from currentTx
instance (which is established byTxManager
, so if you're inside a transaction body, you can do this). First-level cache is per-table descriptor per-transaction; its behavior outside of transaction is undefined.
- Direct implementors of