The platform's in-memory database layer gains a federation engine that materialises result sets from multiple connected databases into a shared working set and evaluates cross-database join conditions against that set. A query that previously required two round trips — fetch from database A, fetch from database B, join in application code — is now expressible as a single SQL statement routed through the federation layer.
Federation engine
- Qualifier-aware join resolution. The SQL parser recognises database-qualified table references and routes each table scan to the correct connection before joining results in memory. Alias and qualifier combinations that previously caused ambiguous-column errors resolve correctly.
- Projection alias propagation. Column aliases defined in a sub-query are visible to subsequent join conditions and projections in the same statement; earlier versions dropped aliases at the sub-query boundary.
- Declarative XML test suite. A set of XML test cases covers join types, qualifier handling, alias propagation, and error paths so regressions surface in the build.
JavaScript API
Ax.db.FederatedQuery. Server-side JavaScript calls this API with a SQL statement and a map of database-name-to-connection to execute cross-database queries without dropping to Java. The result is returned as a standard iterable result object.
Federation operates entirely within the platform's connection-management layer; no dedicated federation server or ETL pipeline is required. The query executor applies the permission model on each constituent connection: a federated query that touches database B is subject to the caller's permissions on database B, not only those on the primary database.