1.13.0

[zantvoort]

Feature and performance release. Highlights: write sets persist mixed-type entity graphs in one dependency-ordered call; compiled query plans reuse processed statements across executions; GraalVM native image support across all stacks; the Storm Gradle plugin; full Java programmatic-transaction parity with Kotlin; and queries and transactions reported as Micrometer Observations. Read, write, and transaction hot paths are leaner throughout. Integration points are instance-scoped, the Ktor integration uses Ktor's built-in dependency injection, and models are null-marked by default.

Added

• Write sets: orm.writeSet() (and Kotlin's scoped orm.writeSet { }) applies one write action to a mixed-type entity collection, ordering statements by foreign-key dependencies (parents first for insert/upsert, children first for remove), batching per type per level, and propagating generated keys by instance identity. insert/upsert extend to the insertion closure (transitively reachable unsaved entities), so a multi-level graph persists in one call; update/remove write exactly the passed entities. AndFetch variants return persisted state in input order. Cycles, and unsaved members passed to update/remove, fail fast before anything is written.
• getResultGroupedBy(...) / getResultGroupedByRef(...) query-builder terminals (all APIs): run the unchanged select and group rows during hydration into an insertion-ordered, unmodifiable map keyed by a parent path — the one-to-many read in a single query. The new TypedMetamodel rejects grouping by a Ref-mapped path at compile time.
• Navigating beyond a Ref in queries (all APIs): filter, order, group, and select through a Ref foreign key with the metamodel (User_.city.country.name where city is a Ref<City>), with the join for the referenced table materialized on demand. A root select still emits the reference as its foreign-key column with no join, and an unreferenced reference join is pruned; a custom selected column beyond a reference adds the join and selects the column. A path may cross more than one reference across distinct tables. The target's primary key is part of the reference: Ref.id() reads it without fetching, so User_.city.id resolves to the foreign key column that holds it and needs no join. This makes a path mean the same thing whether the relationship is declared as an entity or a Ref, since an entity foreign key already resolved its primary key to that column. Beyond-reference nodes implement the new navigation-only Navigable supertype (not Metamodel), so value operations such as getResultGroupedBy / getValue do not compile against them, while the reference node itself stays a value metamodel whose value is the Ref (so getResultGroupedByRef works). groupBy and having accept navigation-only nodes alongside where and orderBy. A reference that returns to a table already on the path, whether a self-reference or a longer cycle, joins that table to itself with one alias per occurrence, so a predicate or ordering resolves against the occurrence the path reached. A nullable reference keeps its outer join in that case, so ordering by a column beyond it does not drop rows. The typed metamodel navigates a cycle two hops deep, since generated metamodels construct their children eagerly and cannot recurse; the query engine has no depth limit, so deeper cyclic paths are named as strings. Ref becomes cheaper to adopt — it removes the eager join from every read while keeping the relationship queryable, so it is the tool for preventing join fan-out in wide or deep graphs.
• Resolving a Ref as part of the query (all APIs): select().fetch(User_.city, User_.city.country) names the references the statement resolves, selecting the referenced table's columns in place of the foreign key column so the reference comes back loaded and Ref.fetch() returns without querying. The record type is unchanged — the field stays a Ref, so the same type serves queries that resolve it and queries that do not — and reference identity, equality and unload() are unaffected. The plan is prefix-closed, so naming User_.city.country resolves User_.city as well and the deeper path is the only one to write; a reference the plan does not name stays a foreign key column. A reference is always a to-one foreign key, so resolving one widens the row without multiplying it, and a cycle stays bounded by the depth the path names (fetch(Node_.parent.parent) is exactly two levels). A nullable reference keeps its outer join, so a null foreign key yields a null reference. fetch accepts Navigable<T, ? extends Data>, which rejects scalar and inline-record paths at compile time; a path that crosses no reference, a reference to a sealed type, and a query that does not select a record are each rejected with a descriptive error. Sql.fetchPaths() reports the resolved references of a statement. Ref.getOrThrow() (all APIs) completes the accessor pair: fetch()/fetchOrNull() resolve on demand, getOrThrow()/getOrNull() read what is already loaded. getOrThrow() never queries and fails with a message naming the fix, so pairing it with fetch(...) turns a plan that no longer covers a path into an immediate error instead of a silent query per row.
• Compiled query plans (core template API): QueryTemplate.plan(...) / QueryBuilder.plan() process a template once into a reusable, immutable QueryPlan, then bind per execution — bind(record), bindValue(value) for primary-key and unique-key lookups, query() for parameter-less statements — skipping the per-call template processing. Repositories reuse cached plans for their fixed-shape operations (single insert/update/remove, delete by id/ref, findById/getById and ref/unique-key lookups, findAll, count/exists, removeAll); JPA templates and interceptor-customized scopes fall back to per-call processing.
• GraalVM native image for Spring Boot: the Storm jars ship reachability metadata, storm-spring contributes AOT runtime hints, and repository scanning joins the AOT phase — native images work without hand-written configuration.
• GraalVM native image for Ktor and plain JVM: storm-core ships a GraalVM feature that reads the compile-time type index at build time and registers the same metadata, activated through the jar's native-image.properties.
• ORMTemplate.builder(dataSource) / builder(connection) (all APIs) with instance-scoped strategies: connectionProvider, transactionTemplateProvider, exceptionMapper, queryObserver. ServiceLoader discovery remains the fallback.
• ExceptionMapper SPI: maps query-execution failures to the exception thrown to the caller, enabling hierarchies such as Spring's DataAccessException.
• QueryObserver SPI: observes query executions (operation, type, execution kind, timing, outcome) for metrics and tracing.
• Statement origin: every executed statement carries what caused it — DIRECT, or FETCH for a statement resolving a Ref — surfaced as the low-cardinality storm.origin tag on Micrometer observations, on captured statements in storm-test, and in SQL log summaries.
• Execution-point SQL logging: the st.orm.sql logger reports every executed statement at DEBUG (per-type child loggers such as st.orm.sql.Owner narrow it), and at TRACE renders parameter values into the statement, producing console-ready SQL. Compiled plans and the template cache stay in effect, so the observed path is the production path.
• SQL log summaries: what one call cost the database, as a single summary — statement count, fetch count, summed database time against elapsed and total time, peak concurrency, and one row per distinct statement ranked by total time, grouped by statement shape so collection parameters of any arity stay one row. Coroutine-aware (sqlLog { }, sqlLogContext(), and transaction { } carry the scope), with a try-with-resources SqlLog.open(...) for Java; the summary reports through the st.orm.sql.perf logger, which is also the switch that enables recording. Opt-in call-site attribution names the application frame behind each row (a coroutine context built with sqlLogContext() carries the launch site, so work on another dispatcher is attributed to the frame that launched it), rows produced or affected are counted per statement (a count a driver or an early-closed stream left inexact is a marked lower bound), reads the transaction's entity cache served without a statement are counted alongside the fetches they saved, and an opt-in hydration-shape display appends each read's declared shape, short (j2 c12 d3: joins, columns, graph depth; flat types show none) or full (naming the joined-entity graph), derived from the type at rendering; writes carry none, since a write touches its own table rather than the graph its type declares. Scopes cover the JDBC and JPA template paths alike.
• Per-entry-point reporting: storm.sql-log.enabled (Spring Boot) and sqlLog = true (Ktor) wrap each unit of work and name the summary after its boundary. In Spring that is every way work enters the application: HTTP requests through a servlet filter, and @Scheduled tasks and message listeners (@KafkaListener, @RabbitListener, @JmsListener, @SqsListener, and the handler methods of class-level listeners) through a proxy around the entry-point method, named after it (ReportJob.nightly) — matched by annotation name so an absent library costs nothing, with storm.sql-log.entry-points replacing the set. Thresholds (threshold.statements, threshold.duration) turn the report into a production guardrail that logs only the units exceeding them, at WARN.
• SqlCapture records executions rather than built statements: each captured statement carries its origin, bound parameter values, and duration.
• springOrmTemplate(dataSource) { transactionManagers } (storm-kotlin-spring): the canonical plain-Spring composition, replacing @EnableTransactionIntegration.
• st.orm.spring.SpringTransactionTemplateProvider (storm-spring): transaction-scoped entity caching for Java under Spring-managed transactions, without reflective probes.
• Ktor plugin: connectionProvider, transactionTemplateProvider, exceptionMapper, and queryObserver slots on install(Storm) { }.
• Ktor plugin: exposes the ORMTemplate and every repository through Ktor's built-in dependency injection, each under its interface type (val visits: VisitRepository by dependencies); disable with registerDependencies = false.
• Ktor plugin: multiple databases via database("name") { } blocks (own template, repositories, validation, migration, lifecycle), in code or under storm.databases.<name>.* in HOCON; access via orm("name"), repository<T>("name"), and named dependency injection.
• New storm-micrometer module: MicrometerQueryObserver reports query executions as storm.query Micrometer Observations, overridable via a custom ObservationConvention.
• Ktor plugin: binds query observations automatically when an ObservationRegistry is registered, tagged storm.database=<name>.
• transactional { } route DSL (storm-ktor): each route runs in its own transaction with the same options as transaction { }, bound to the first template the handler touches.
• Storm Gradle plugin (id("st.orm"), Gradle Plugin Portal, BOM-aligned): one application imports the BOM, adds the core dependencies, wires the metamodel processor (KSP or annotation processor), selects the Kotlin compiler-plugin variant matching the project's Kotlin version (2.0 through 2.4), and sets the Java preview flags; a storm { } extension covers opt-outs; configuration-cache compatible. Requires Gradle 8.5+. The plugin is released from the same tag as the artifacts it wires, so its version and the Storm coordinates it adds always match.
• Programmatic transactions for Java: Transactions.transaction(...) (storm-java21) with Kotlin transaction { } semantics — all seven propagation modes, isolation, timeout, read-only, rollback-only, and callbacks — blocking and virtual-thread friendly. Options via the st.orm.TransactionOptions record.
• Transaction.onCompletion(committed) (all APIs): the completion callback for work that has to happen either way, such as releasing a lock, receiving whether the transaction committed. The three callback kinds share one registration order, skipping the ones the outcome does not apply to. A failed callback surfaces as TransactionCallbackException with an isCommitted() flag — the transaction completed and a side effect failed afterwards, which is the case a retry must not repeat — with the first failure as the cause and the rest suppressed; after a rollback caused by an exception, the wrapped failure attaches to that exception as suppressed rather than replacing it.
• Shared transaction vocabulary in storm-foundation: TransactionPropagation, TransactionIsolation, TransactionTimedOutException, UnexpectedRollbackException, and the language-neutral Transaction handle.
• Sql.dataType(): the statement's primary entity or projection type, now derived for SELECTs too and reported to query observers.
• Java Spring programmatic-transaction bridge: SpringTransactionTemplateProvider runs Transactions.transaction(...) blocks through Spring's PlatformTransactionManager, joins active @Transactional transactions, and picks the manager per template DataSource. SpringOrmTemplate.of(dataSource, transactionManagers) is the canonical Java composition.
• Shared Spring Boot auto-configurations in storm-spring (st.orm.spring.boot): StormTransactionAutoConfiguration, StormValidationAutoConfiguration, and StormProperties, used by both starters; keys unchanged.
• SQL failures translate to Spring's DataAccessException hierarchy: SpringExceptionMapper maps on vendor code with SQLException-subclass and SQL-state fallback, auto-configured by both starters (storm.exception-translation.enabled=false to disable). Failures without a SQLException cause keep Storm's own exceptions.
• Spring Boot starters bind query observations automatically when an ObservationRegistry bean is present (Actuator provides one); override with an ObservationConvention or QueryObserver bean, or disable via management.observations.enable.storm.query=false.
• OtelDatabaseObservationConvention (storm-micrometer): opt-in OpenTelemetry database semantic conventions (db.system.name, db.operation.name, db.query.text) on query observations, via storm.observations.semantic-conventions=otel or the Ktor container.
• Trace context in SQL statements: the SqlCommenter hook (all stacks) appends per-execution comments after processing, and TraceContextSqlCommenter (storm-micrometer) emits the current span as a W3C traceparent comment. Opt-in (storm.tracing.sql-comments=true|sampled, or the Ktor sqlCommenter slot) since per-execution comments defeat statement caching; a sampled-only mode limits the cost to sampled traces, and hostile content is rejected and padded.
• Transaction observations: every physical transaction reports as a storm.transaction Micrometer Observation (duration, outcome, propagation, read-only), without double-counting joined blocks; QueryObserver gains a default no-op transaction hook.
• @EnableStormRepositories(basePackages = ...) (storm-spring, both stacks): switches on repository scanning in plain Spring (mirroring @EnableJpaRepositories) and doubles as the explicit override in Spring Boot. Adapter constructors (base packages, template bean name, prefix) let multi-template applications define one bean per repository set.
• @DataStormTest test slice in the new storm-spring-boot-test-autoconfigure module (the @DataJpaTest counterpart): starts only the DataSource, Storm's auto-configuration, and SQL initialization, replaces the data source with an embedded database, and rolls back per test. One module serves both starters on Spring Boot 3 and 4 (spring.test.database.replace=none opts out for Testcontainers).

Changed

• The groupBy and orderBy metamodel overloads resolve a path to the columns a predicate on that path uses: a foreign key contributes its foreign key column(s) on the referencing table, once and without joining the referenced table, and an inline record contributes its component columns. The core API previously expanded a foreign key to every column of the referenced table (joining it, and listing the key columns of a compound-key target twice), while the Kotlin and Java 21 APIs rejected compound foreign keys and inline records outright. All three APIs now share the same expansion, and descending order applies DESC to every expanded column.
• The primary key reached through a foreign key resolves to the foreign key column(s) on the referencing table for entity foreign keys as well, matching references: Visit_.pet.id names visit.pet_id in predicates, templates, groupBy and orderBy alike, without joining the referenced table. A single component of a compound key reached through a foreign key still resolves in the referenced table, which is joined on demand. Generated metamodels now flatten by the documented contract: an inline record expands into its component columns and every other node flattens to itself, so generated and reflection-built metamodels agree.
• The value a reference metamodel reports is declared nullable (Java): a reference metamodel is generated per target type, so one class serves every property that references it, nullable and non-null foreign keys alike. A nullable foreign key holds no reference, so getValue returns null; the annotation processor declared it non-null while KSP already declared it nullable. Both now agree. Value extraction beyond a reference is unaffected, since a beyond-reference node is navigation-only and has no value to report.
• JSON columns in the metamodel (all APIs): a converted column is stored as one type and held as another, and the metamodel now keeps both — it addresses the column by its stored type (String for @Json) so a predicate compares against the stored JSON, while value extraction returns the type the record declares. Previously the annotation processor substituted the stored type for both, generating a metamodel that did not compile, so @Json could not be used on any entity that generates one; KSP ignored the annotation entirely, so the same model produced different metamodels per language. The runtime metamodel mistook a converted record field for an inline record, resolving paths to columns the table does not have; it now recognizes the converter as the model always has.
• Java models are null-marked by default (JSpecify-aligned), giving Java and Kotlin one contract: components are non-null unless annotated @Nullable or inside a @NullUnmarked scope, nearest marker wins. Nullable is load-bearing — a bare @FK is non-null and joins INNER, @Nullable @FK is optional and joins LEFT. JSpecify stays an optional, reflectively resolved dependency.
• Entity and projection records are constructed through generator-emitted instantiators (annotation processor and KSP) instead of Constructor.newInstance; models without the generators fall back to reflection. This removes the last reflective call from row mapping — no reflection config for native images, no opens clauses for model packages.
• Leaner read and transaction hot paths: eager terminals skip the fetch-size hint (no transaction wrapping for auto-commit queries on PostgreSQL), cached entities skip column decoding, constructor metadata is precomputed, observation is free when nothing observes, and transactions restore connection isolation/read-only only when a block changed them (two fewer PostgreSQL round trips).
• transaction { } / transactionBlocking { } bind to the first template that executes inside the block (options recorded, transaction opened on first use); a block that touches no template is a no-op, and mixing transaction providers fails fast.
• The TransactionTemplate SPI is reshaped from execute() to open()/complete() handles for the lazy binding.
• Ambiguous ServiceLoader resolution of connection or transaction template providers throws a descriptive error naming the candidates instead of silently picking one; enablement is re-evaluated per resolution.
• The Spring Boot starters contribute Spring-aware ConnectionProvider/TransactionTemplateProvider beans (backing off to user beans) and consume optional ExceptionMapper/QueryObserver beans.
• Ktor is upgraded 3.1.2 → 3.4.3, and storm-ktor tracks Ktor's toolchain: Ktor 3.4 requires Kotlin 2.3 and kotlinx-coroutines 1.10, so the module is compiled on Kotlin 2.3 and declares that stdlib for consumers. Storm's other modules stay on the Kotlin 2.0 toolchain, so only Ktor applications move. ktor.version now lives in the parent pom.
• The Ktor plugin's configuration class is renamed StormConfiguration → StormPluginConfig (vs core's StormConfig); application code is unaffected unless it named the type explicitly.
• The default JDBC transaction machinery moved from storm-kotlin to storm-core as Java, so core-only Java applications get real JDBC transactions; blocking orchestration lives once in core (TransactionRunner), and the Kotlin transaction enums and exceptions moved from st.orm.template to st.orm (imports change, behavior identical).
• Spring repository scanning, autowire-candidate resolution, and AOP proxying are single-sourced in storm-spring (AbstractRepositoryBeanFactoryPostProcessor); the Kotlin adapters moved to st.orm.spring.kotlin and override methods instead of properties (override fun getRepositoryBasePackages(), etc.). Java subclasses are unaffected.
• One starter per application: the Java and Kotlin stacks share class names, so storm-spring-boot-starter and storm-kotlin-spring-boot-starter cannot be mixed; they share their transaction, validation, and properties auto-configurations from storm-spring.
• The auto-configured ORMTemplate and startup schema validation condition on a single DataSource: applications with several DataSource beans boot cleanly (the template backs off, or binds the @Primary pool).
• The repository AOP post-processor bean is renamed to stormRepositoryProxyingPostProcessor.
• Java applications without a PlatformTransactionManager no longer get a Spring-bound ConnectionProvider; they fall back to Storm's own JDBC transactions.
• Spring Boot: SQL failures now surface as Spring DataAccessException subtypes instead of PersistenceException (auto-configured). Update catch blocks and rollback rules, or set storm.exception-translation.enabled=false to keep the previous behavior.
• EntityCallback.beforeDelete/afterDelete are renamed beforeRemove/afterRemove (all APIs), matching the remove methods that fire them and the naming of the other three callback pairs. delete stays the statement-level vocabulary (delete(), deleteFrom(...)), and a query-builder delete carries no entity, so it does not fire these. Kotlin overrides and Java overrides marked @Override fail to compile; a Java override without @Override compiles and stops being called, so search for the old names.
• After-callback entity state (all APIs): an "after" callback observes what the calling method reports to its caller, rather than always the entity as sent. The methods that return nothing report the entity as sent (no key is read back, so none can be reported), the *AndFetchId(s) methods report it carrying the primary key the database assigned, and the *AndFetch methods report the row as read back — so afterInsert can finally reference what was just inserted, and afterUpdate on updateAndFetch sees version increments and trigger-applied changes. The method name at the call site is what determines this; a callback that needs the key has to be driven by a method that reports one. Write sets follow the same rule: keys retrieved only to bind foreign keys on dependent rows stay out of the callbacks, and on the fetch variants every written member is read back, so a callback observes the same thing whether its entity was passed or reached by the insertion closure. Breaking for callbacks that relied on afterInsert receiving an unset key, or that compared the callback entity against the instance passed in.

Fixed

• Transaction callbacks of a block inside an externally managed transaction fire when that transaction completes, not when the block returns. A transaction { } block inside a Spring @Transactional method fired its onCommit callbacks as soon as the block ended: the callback ran while the transaction was still open, and reported a commit even when Spring went on to roll back. Two mechanisms close this. A block that joined the physical transaction through a query hands its callbacks to the manager that owns it, via the new TransactionHandle.joinedExistingTransaction() / deferCompletion(...) SPI methods. A block that never binds to a template — it only registers callbacks — settles through the new stateless ExternalTransactionProvider SPI, which detects the externally managed transaction active on the thread; storm-spring implements it over TransactionSynchronizationManager, carrying no configuration, so its ServiceLoader discovery cannot affect template behavior (per-context configuration stays on the composed providers). In both cases the callbacks register as Spring transaction synchronizations in registration order, and a setRollbackOnly() in an unbound block marks the Spring transaction, mirroring how a joined scope marks its parent (NESTED stays bounded at its savepoint). A REQUIRES_NEW block owns its transaction and keeps firing its own callbacks; a callback failure deferred to Spring follows Spring's completion rules and is logged rather than thrown. The result is one contract everywhere: an entity callback registering onCommit through a joining block behaves identically under Storm-managed and Spring-managed transactions.
• The interface order of the dynamic proxies behind monitored resources (streams, cursors) is deterministic, so GraalVM proxy registrations always match the proxies created at run time.
• Entity callbacks fire on the dialect-specific insert paths. PostgreSQL, MariaDB and SQL Server override the key-returning insert to use their own statement, and those overrides ran no lifecycle callbacks at all: a beforeInsert filling in audit fields was skipped and the row was written without them. The widest case was SQL Server's batch insertAndFetchIds, which took the override for every generation strategy other than NONE, identity keys included. MySQL, Oracle, H2 and SQLite were unaffected.
• A multi-column key comparison renders as the form a planner indexes. Storm emitted a row-value tuple wherever the dialect accepts one, and MariaDB reduces a tuple to its conjunction in a SELECT but not in an UPDATE or a DELETE, where it considers no index at all and scans the table for every row it identifies: a batch of keyed updates became quadratic in the table, and because a scanning statement locks what it examines, two batches against one table deadlocked rather than merely running slowly. Whether a tuple helps is a property of the operator and the planner rather than of the grammar, so dialects now answer rendersTupleComparison(operator, rowCount) and one implementation acts on it. A single row of equality never renders as a tuple — measured on MariaDB, MySQL, PostgreSQL and H2 the expansion ties or beats the tuple for that shape, and it is the shape behind every keyed update, delete and lookup. A multi-row list keeps the tuple, which is where it pays.
• Row identity for entity-typed primary keys in the entity cache, refs and write sets. An entity-typed primary key compared structurally, so row identity depended on every non-key column of the key entity and its foreign key closure: two representations of the same row failed to correlate whenever such a column did not round-trip bit-exact (a second-precision timestamp column, a database-managed column, a numeric scale difference). Fetch-after-write then threw even though the row was written, and the remove and keyed-member orderings silently dropped dependency edges, worst case a referential integrity violation. RowIdentity normalizes a primary key to the identity the SQL layer binds — an entity-typed id reduces recursively to its own primary key, a ref id to the key it wraps, a composite key component-wise — detected through the pluggable reflection support, so Java records and Kotlin data classes behave alike. Scalar keys are returned unchanged through a per-class cached decision.
• Id-based lookups (findAllById, whereId) on an entity whose primary key is itself an entity. The key values resolved by type, which is ambiguous when the key entity's table appears more than once in the root's join graph — a junction row whose second foreign key reaches the same table again — and the query failed with Cannot uniquely identify object in expression. Object-expression resolution now falls back to the root's primary key path when the value type matches the primary key type, mirroring the existing fallback for scalar values.
• The metamodel generator resolves a field's type from the canonical constructor. It scanned every constructor of a record and returned the first parameter whose name matched the field, so a convenience constructor that reuses a component name for a parameter of a different type — a record holding a Ref<City> that also takes the City it refers to — could decide the field's type, depending on which constructor the compiler enclosed first. Type resolution and isDataType now agree.
• Spring repository scanning reads candidate metadata through the classloader. Type-filter matching resolves each candidate's supertypes by name through the scanner's resource loading, which dispatched classpath lookups to every ProtocolResolver registered on the application context: a resolver bound to its own scheme, such as Spring Cloud AWS's s3 resolver, was consulted for these lookups and logged a warning per resource, because its backing client bean is not available yet while bean factory post-processing runs.
• upsertAndFetchIds on SQL Server with an auto-generated primary key. An auto-generated key routes the upsert to insert rather than to MERGE, but the insert branch bound a shared prepared statement and read its generated keys, bypassing the dialect override that exists because the driver cannot report generated keys for a JDBC batch; the call failed with The statement must be executed before any results can be obtained. The new SqlDialect.supportsBatchGeneratedKeys() names the constraint (default true, false for SQL Server): where a prepared batch cannot report its keys, the branch goes through the public insertAndFetchIds so the dialect emits the statement that carries them, and elsewhere the insert partitions keep sharing one prepared statement.

Removed

• @EnableTransactionIntegration and SpringTransactionConfiguration (storm-kotlin-spring): the JVM-global transaction manager list is gone. Use springOrmTemplate(...) or the starter; multiple contexts in one JVM no longer interfere.
• The Spring modules no longer register ServiceLoader providers, and the reflective Spring probes are removed from storm-core and storm-kotlin: a plain ORMTemplate.of(dataSource) inside a Spring application runs independently of Spring transactions — compose with springOrmTemplate or the builder. This also removes the mixed-transactions guard.
• Providers.getConnection / Providers.releaseConnection: connections are acquired through the template's own connection provider.
• SpringConnectionProviderImpl, SpringTransactionTemplateProviderImpl, and TransactionAwareConnectionProviderImpl are replaced by the public SpringConnectionProvider and SpringTransactionTemplateProvider.
• st.orm.spring.impl.ResolverRegistration: the autowire-candidate resolver is installed by the scanning engine itself.
• storm-ktor-koin: Ktor's built-in dependency injection is the supported DI path; the docs include the Koin recipe.
• @SqlLog and its repository-proxy processing: the annotation covered only repository proxies, disabled compiled plans and the template cache for annotated calls, and stopped capturing at the first suspension point. The name now denotes what the annotation wanted to be: the built-in SQL log (sqlLog { }, SqlLog.open(...), and the st.orm.sql logger tree), which covers every execution without those constraints.

Security

• Schema validation reads database metadata through bound parameters instead of escaped string literals (DatabaseSchema) — defense in depth; no metadata query is assembled from concatenated values.
• The kotlinx-serialization module validates that a Ref target resolves to a Storm Data type before loading it, and does not run static initializers until that check passes.

---

This discussion was created from the release 1.13.0.