![\"\"/](\"https://orbitalhq.com/assets/title-card-DCtABlAo.jpg\")
0.39.1-M1 is the first milestone of 0.39 — the largest change Orbital has had. It has been in development since\nApril, and it changes the shape of the product in a few significant ways.
\nThe headline is workspaces: a single Orbital instance can now run many independent schemas, each with its\nown projects, its own compiled schema, its own connections and its own query context. Everything downstream of\nthat — auth, secrets, search, history, caching, the language server — was reworked to be workspace-aware.
\nAlongside that: a secrets manager with five backends, a data validation framework, Copilot\n(chat-driven querying and schema building), an MCP server so external agents can query your data mesh, and\na new code editor that edits whole projects rather than single queries.
\nTwo features we announced over the summer also ship here for the first time: collection options\n(limit, offset, orderBy, uniqueBy on any query, pushed down to the source where it can take them), and\n@DeleteOperation / @SqlQuery for the database connectors.
As a milestone, 0.39.1-M1 is for early adopters and teams who want to test ahead of the full 0.39 release.\nExpect rough edges, and tell us about them.
\n\nOrbital checks for a license.json on startup. When you first sign in, Orbital contacts the license server at\nhttps://account.orbitalhq.app, downloads a free license and installs it. In most environments this needs\nno setup.
If no license is found, Orbital issues a short-lived fallback license so the server still starts — but that\nfallback only lasts 30 minutes, after which the UI shows a blocking overlay.
\nOrbital searches these paths in order, and the first valid license wins:
\n--vyne.license.path (if set)${vyne.app.data.path}/license.json — by default ./orbital_data/license.json~/.orbital/license.json/opt/var/orbital/license/license.jsonFor air-gapped deployments that can’t reach the license server, Orbital supports an air-gapped mode that\ndisables usage reporting. Get in touch if you need it.
\nSee configuring your license for the full detail.
\nOne improvement worth calling out: an expired license no longer terminates the JVM. The old LicenseMonitor\ncalled exitProcess(0) on expiry. That’s gone — expiry now surfaces in the UI and is governed by the license\npolicy instead of killing the process.
The boolean toggle is gone, replaced by a three-state enum:
\nvyne: toggles: workspace-mode: None # None | Workspace | OrgAndWorkspace| Mode | Behaviour |
|---|---|
None (default) | Single workspace. No workspace prefix in UI routes, no selector. Behaves as Orbital always has. |
Workspace | Workspace routing. UI routes are prefixed /{workspaceId}/... |
OrgAndWorkspace | Org and workspace routing: /{orgId}/{workspaceId}/... |
If you were setting workspacesEnabled: true, that key is now ignored and you will silently fall back to\nNone. Set workspace-mode instead.
A Flyway migration adds a workspace_slug column across eight history tables, adds orgId to\nquery_error_event and trace_event, backfills both with default, and enforces NOT NULL. Indexes on\n(orgId, workspace_slug) are created alongside.
The migration runs automatically. On instances with a large query history, the SET NOT NULL statements take\na table lock, so budget for some downtime on the first boot after upgrading.
The same migration drops the Postgres row-level-security policies on those tables. RLS was keyed on\ncurrent_user, which never worked with a shared connection pool. Org and workspace isolation is now enforced\nin the application layer via org-membership checks and explicit orgId / workspace_slug filters on every\nquery.
Rows written before this milestone cannot be attributed to a workspace — they were never stamped — so they stay\nas default/default.
pipelines/pipeline-jet is gone from the build, along with the pipeline transports that only it used (S3,\nSQS, Cask, file-watcher, HTTP listener, JDBC, Kafka, Redshift, logging sink, polling query input) and the\ntransform stage.
This is the standalone pipeline runner, which has been unmaintained and undocumented for a long time.\nStreaming queries are unaffected — stream { } queries run through pipelines/stream-engine, which stays.
H2DatabaseSupport has moved to test sources. The drivers shipped to end users are now Postgres, MSSQL,\nOracle, Redshift, Snowflake and Databricks. If you had an H2 connection defined in connections.conf, it will\nfail to resolve.
Orbital is built on Spring Boot 4.0 and Jackson 3. If you write custom Orbital extensions — custom taxi\nfunctions, custom connectors, anything compiled against Orbital’s jars — you will need to migrate. The main\nthings that bite:
\ncom.fasterxml.: Any generic bounds in Kotlin.spring-boot-health, -jdbc, -hibernate, -mongodb, and the\nmatching test slices).Comparisons between numbers of different JVM types now coerce both sides to BigDecimal and compare with\ncompareTo. Two consequences:
Int vs\nBigDecimal) compared correctly; others silently failed.Equal and NotEqual are now scale-insensitive. 2.50 == 2.5 is now true where it was previously\nfalse, because BigDecimal.equals treats different scales as different values.Taxi’s Long is backed by BigInteger, which previously had no branch in the arithmetic calculator at all\nand errored with “Unsupported number type”. Long arithmetic now works, and division on Long truncates —\nthe same semantics as Int.
right(input, n) was returning characters counted from the left of the string. It now returns the last n\ncharacters, as the name and documentation always said. If you worked around the old behaviour, remove the\nworkaround.
Given operation confirm(OrderId, note : String) and an OrderId in context, the old code would bind the\nOrderId’s value to note — because everything is assignable to String, so a raw primitive parameter\nmatched whatever value happened to be nearby.
Parameters typed as raw primitives (String, Int, …) or Any are now populated only from an exact\ntype match already in context — never an inherited match, never a graph query. Otherwise they resolve to null\nand normal nullability handling applies.
A default declared in the signature is unaffected, because it names the parameter it belongs to rather\nthan being matched to it. That remains the supported way to populate a raw primitive.
\nIf a schema was relying on the old behaviour, the operation will now be invoked with a null (or not invoked at\nall, if the parameter is required). Give the parameter a semantic type, or a default.
\nHTTP query responses now follow standard content negotiation, in this order:
\nAccept header wins.@Xml, @Csv) is used.Previously the model’s declared format always won, so a model annotated @Xml requested with\nAccept: application/json still came back as XML. If you have a client relying on that — sending an Accept\nheader it didn’t mean and getting the model’s format regardless — it will now get what it asked for.
An absent Accept header is treated as “no preference” rather than being forced to JSON, so it defers to the\nmodel’s declared format. This applies uniformly to the /api/taxiql endpoints and to routed saved queries.\nStreaming responses (SSE and WebSocket) negotiate separately and are unchanged.
In Workspace or OrgAndWorkspace mode, all workspace-scoped APIs move under /api/{orgId}/{workspaceId}/...,\nand published query endpoints move to /api/{orgId}/{workspaceId}/q/....
In None mode — the default — legacy routes such as /api/schema/types and /api/q/myQuery continue to work\nexactly as before. This includes the anonymous-access security matcher, which now picks the pattern matching\nthe active mode.
GET /tokens returned a flattened\nMap<ServiceName, List<AuthScheme>>. It now returns a row-shaped listing that preserves the package each\nentry came from, plus a sibling field carrying per-package parse errors.workspace.conf are now secret references. Inline GitCredentials / GitSshAuth\nare replaced by a GitAuthentication reference that points at a secret name resolved through the workspace’s\nsecrets manager at fetch time.@XmlElement metadata and\nfield access rather than by introspecting CXF’s generated Java getters. This fixes acronym and casing\nmangling (getSISOCode was becoming SISOCode rather than sISOCode), but if you had types hand-shaped to\nmatch the old mangled names, they now need to match the WSDL names./stubs → /local-environment, /catalog/diagram →\n/mesh, /workspace → /workspaces. The old query editor at /query/editor is replaced by\n/code-editor.LIST_SECRETS and EDIT_SECRETS were added and are granted to the admin and platform\nmanager roles in the bundled default role definitions. Deployments that already have a roles.conf on disk\nwill not pick these up automatically — Orbital only writes the defaults when the file is absent. Add them by\nhand if you want the secrets UI available to existing roles.A workspace is a named context that compiles to a schema. Everything schema-driven in Orbital — queries,\nstreams, published endpoints, the catalog, the search index — operates within one.
\nTypical uses:
\nAn organisation is the tenant above that. A cluster serves one or more organisations; on-prem deployments\ntypically have one, and a default org is created on first boot if none exists.
\nvyne: toggles: workspace-mode: OrgAndWorkspaceWhen enabled, a combined org-and-workspace selector appears in the header. Collapsed, it shows the active\nworkspace above the active organisation; expanded, it lists the workspaces in the org, with a nested\nSwitch organisation submenu and management actions. In Workspace mode the org half is hidden.
Every page — catalog, code editor, projects, activity — is scoped to the active workspace, and the URL\nreflects it.
\nTwo things need storing: which orgs and workspaces exist, and what projects make up each workspace. Both are\nconfigured under vyne.orgs:
vyne: orgs: store: FILE # FILE | IN_MEMORY | DATABASE config-path: ./orbital_data| Backend | Best for | Writable from the UI? |
|---|---|---|
FILE (default) | Local dev, single-node on-prem | Yes |
IN_MEMORY | Ephemeral environments, tests | Yes, until restart |
DATABASE | Multi-node and cloud deployments | Yes |
The file backend reads an organisations.conf from config-path, with one workspace.conf per workspace\nunderneath:
orbital_data/ organisations.conf workspaces/ acme-bank/ production/workspace.conf analytics/workspace.confThe database backend stores the same HOCON content as text blobs in org_config, workspace_config_entry and\nworkspace_config, using Spring Data repositories over Orbital’s existing datasource. Because the stored\ncontent is byte-identical to the file format, you can move between backends without transforming anything.
Workspace config also materialises back to disk on boot, so a cloud deployment with a populated database and a\nfresh disk rehydrates correctly. The file backend leaves hand-edited content alone.
\n\nThe bulk of the work in 0.39 was making everything downstream of the schema respect workspace boundaries. Things\nthat used to be global singletons and are now per-workspace:
\nInvokerFactory, from that workspace’s own connection registry.services.conf and auth.conf. Service discovery and outbound auth resolve through per-workspace\nregistries, so HOCON substitution sees that workspace’s own environment variables. Previously a single global\nregistry meant auth.conf files discovered through a workspace’s project additionalSources were silently\nignored, and outbound HTTP calls went out unauthenticated.{basePath}/{orgId}/{workspaceId}/,\nrebuilt only for the workspace whose schema changed.Workspaces created through the API or by dropping a directory on disk are registered live — no restart needed\nfor schema compilation, search indexing or route registration.
\n@RequiresOrgPrivilege replaces @PreAuthorize("hasAuthority(...)") across roughly 150 production endpoints.\nIt resolves the request’s {orgId} path variable and delegates the decision to an OrgAuthorityService, which\nhas two implementations:
vyne.security.open-idp.roles.format=propelauth, per-org roles are read from the JWT’s\norg_id_to_org_member_info claim.This unblocks users who belong to multiple organisations, who previously hit\n“You are a member of multiple organisations”.
\nOrg membership is now enforced on the workspace endpoints themselves. Previously any authenticated user could\nlist or create workspaces in any tenant by putting that tenant’s slug in the URL. Organisations are also\nauto-provisioned from JWT claims on first sign-in, so workspace creation works on a fresh deployment.
\nCopilot is a chat interface to your data mesh. It runs in two modes:
\nThe mode is chosen before you send the first message, and pinned for the life of the conversation — reopening\na conversation restores the mode it was started with.
\nConversations are persisted with their history, can be renamed, and are listed in a sidebar. File uploads are\nsupported and scoped to the workspace. In Build mode, edits stream into Monaco models as they arrive, so you\nwatch the agent write.
\nCopilot is a separate service. Point Orbital at it and turn on the toggle:
\nvyne: toggles: copilot-enabled: true copilot: endpoint-url: http://localhost:9028 upload-store: local local-store-path: ./orbital_data/copilot/uploadsRequests to the Copilot service carry the caller’s JWT, and all calls are scoped to the current org and\nworkspace.
\nOrbital exposes a Model Context Protocol server, so Claude, Cursor, IDE\nagents and your own tooling can ask the same questions a Copilot user can.
\nvyne: toggles: mcp-server-enabled: trueOne endpoint is mounted per workspace:
\n/api/{orgId}/{workspaceId}/mcpMounting it under the workspace path means it inherits the existing org-membership gate from the security\nfilter chain. No tool takes orgId or workspaceId as an argument — the URL is the only source, so an MCP\nclient can’t reach across into another tenant’s data by changing a parameter.
The server exposes a single ask tool:
| Field | Description |
|---|---|
question | The question, in natural language |
execute | Run the generated query and return rows, or just show the query that would run |
It answers with the natural-language answer, the generated query, a queryHistoryId you can use to\ninspect the run in Orbital’s history, the result rows, and any queryError or diagnostics.
The tool description and the server’s MCP instructions are generated from the workspace’s own schema, so\nclients know what data they’re pointed at.
Authentication accepts a PropelAuth API key presented the standard way — Authorization: Bearer <token> —\nwhich is what MCP clients send. Orbital now discriminates structurally: a bearer credential shaped like a JWT\nis validated as one, anything else is validated as an opaque API key. Previously an API key had to be sent\nwithout the Bearer prefix, which MCP clients can’t do.
The old single-query editor is replaced by a multi-file editor at /code-editor.
taxi.conf, READMEs, connections.conf, nebula\nscripts and everything else is visible — not just .taxi files. Content is fetched lazily when you click.\nPer-file error counts show in the tree.Two long-standing editor bugs are fixed. Editing or saving a file used to produce\nSymbol X is already declared errors for every symbol in the file, caused by the same file being registered\nunder two different URIs — once through the language server and once through the schema editor’s in-memory\nedit application. And edits to files outside src/ were being nested under src/, while edits already\naddressed with a src/ prefix were double-nested at src/src/....
Secrets are now first-class. Reference one anywhere in your config the same way you’d reference an environment\nvariable:
\nconnections.jdbc.warehouse { url: "jdbc:postgresql://warehouse.example.com:5432/prod" password: ${secrets.DB_PASSWORD}}Real values never enter the merged HOCON config. The placeholder resolves to an opaque token that the consumer\nresolves at the point of use — at connection time, at outbound-request time, at git-fetch time — so a secret\nlives in a call frame and never in long-lived state. Rotating a secret takes effect without a restart.
\nPick one with vyne.secrets.backend:
| Value | Backend |
|---|---|
InMemory (default) | In-process. Tests and demos only. |
File | Local file, age-encrypted (X25519 + ChaCha20-Poly1305). Dev only — the key sits next to the data. |
Infisical | Infisical, cloud or self-hosted, via universal auth |
Aws | AWS Secrets Manager |
Vault | HashiCorp Vault KV v2 |
Gcp | Google Cloud Secret Manager |
Each backend maps Orbital’s scope hierarchy onto its own naming rules — paths in Vault and Infisical, flat\nprefixed names in AWS, __-separated segments in GCP, whose names can’t contain slashes.
| Scope | Visible to |
|---|---|
Server | every workspace on this server |
Organisation | every workspace in that organisation |
Workspace | only that workspace |
Reads cascade — workspace, then organisation, then server — and the narrower scope wins on a name collision.\nThere is no global namespace that bypasses scoping.
\nSecrets are managed in the UI under Secrets, and over REST:
\nGET /api/{orgId}/{workspaceId}/secretsGET /api/{orgId}/{workspaceId}/secrets/{scope}POST /api/{orgId}/{workspaceId}/secrets/{scope}PUT /api/{orgId}/{workspaceId}/secrets/{scope}/{name}DELETE /api/{orgId}/{workspaceId}/secrets/{scope}/{name}POST /api/{orgId}/{workspaceId}/secrets/refreshReads need LIST_SECRETS, writes need EDIT_SECRETS. No endpoint ever returns a secret value — responses\ncarry name, scope, description, last-updated and version only. Server-scoped secrets are listable but\noperator-managed: writes to that scope are rejected with a 403.
A caller at /api/acme/prod/... can only touch Workspace(acme/prod) and Organisation(acme) — not another\norg’s or another workspace’s secrets.
Every backend is wrapped in a caching decorator with a 15-minute TTL (configurable via\nvyne.secrets.cache.ttl and .max-size), write-through invalidation, and the refresh endpoint above for\nforcing a reload after rotating a secret out of band.
Adding a git project now captures credentials — none, username/password, token, or SSH key — as references to\nsecrets rather than as credentials embedded in workspace.conf and travelling through git. The UI rejects\nplaintext entries at submit, since they would defeat the point.
Credentials resolve inside JGit’s configure(transport) call. SSH keys load as bytes, so no key is ever\nwritten to a temp file.
See managing secrets for the full setup.
\nYou can now declare validation rules against your types, and control what happens when data breaks them.\nBecause rules are declared against types, you define them once and they’re enforced everywhere that type\nappears, whichever service the data came from.
\nThree parts: declare rules with annotations, activate them with @Valid, decide what happens with\n@OnValidationFailure.
import com.orbitalhq.validation.NotEmptyimport com.orbitalhq.validation.Valid\n@NotEmptytype Name inherits String\n@Validmodel Person { name : Name}A Person arriving as { "name": "" } produces one violation — rule com.orbitalhq.validation.NotEmpty, at\npath name, severity Error — and by default rejects the query with an HTTP 400. Remove the @Valid and the\nsame data flows through untouched. Rules do nothing until something activates them.
@NotEmpty, @MinLength, @MaxLength, @Pattern, @Min, @Max, @MultipleOf, @MinItems, @MaxItems,\n@UniqueItems, @Email, @Uuid. That’s feature parity with OpenAPI’s schema validations. Every rule takes an\noptional message and severity (Info, Warning or Error).
Rules can go on a type, a field, or a query parameter, and they’re inherited — a rule on Name applies to\nevery type inheriting from it.
Two rule ids are produced by the engine rather than declared: NotNull, when a non-nullable field inside a\n@Valid scope holds a null, and ParseFailure, when a value can’t be parsed into its declared type.
@OnValidationFailure(action = ValidationAction.Warn, threshold = Severity.Error)query GetOrder { find { Order }}| Action | Behaviour |
|---|---|
Reject | Fails the request with an HTTP 400 and a structured violation report |
Warn | Data passes through. Violations are still logged and reported |
Drop | Skips the offending record and keeps going. Never silent — every drop is reported |
threshold sets the minimum severity that triggers the action. All violations are reported regardless of\nthreshold — the threshold only decides which are severe enough to act on. That pairs well with per-rule\nseverity: mark rules you’re not yet confident about as Warning, watch them in your logs, promote them to\nError once you trust them.
Defaults are per query kind: find rejects at Error, stream drops at Error. Query arguments always\nreject — dropping a record makes no sense when the record is the caller’s own input.
Violation paths are precise: cast.actors[1].actor.name, not just “somewhere in the response”.
Validation runs on query arguments, on data returned by services, and on streaming pipeline inputs.
\nSee validating data and the\nrule reference.
\nOrbital now ships an Oracle driver, with full write support: Insert and generated-primary-key Upsert use\nINSERT ... RETURNING, Update runs per-row batches, and a user-supplied-PK Upsert uses MERGE. Oracle’s\nMERGE can’t return rows, so the invoker echoes the input back, matching how the Postgres upsert behaves.
Table generation accounts for Oracle lacking CREATE INDEX IF NOT EXISTS and needing explicit lengths on\nindexed VARCHAR2 / CLOB columns. jOOQ’s dialect is resolved by probing the live connection rather than\nassuming a version, so Orbital doesn’t emit CREATE TABLE IF NOT EXISTS (23ai and later only) against an\nolder database. The probe is cached per connection.
Metadata reads are scoped to the connecting user’s schema. Oracle has no schema concept separate from the\nuser, so without that scoping Orbital crawled SYS, SYSTEM and every other user’s schema.
Table introspection — the connection UI’s table list, and the schema generator behind import from database —\nwas built on SchemaCrawler, which required a full catalog crawl. On a warehouse that’s slow to the point of\nunusable, and it had no plugin support for Snowflake or Databricks.
\nIt’s been replaced with targeted DatabaseMetaData calls. What that changes for you:
listConnectionTables and getTableMetadata ran their blocking\nJDBC calls on the Netty event loop, which starved the whole server until it was restarted. They now run on\na bounded elastic scheduler.includeColumns / includeIndexes query\nparameters on the tables endpoint.CLOB maps to String instead of failing generation outright, and Postgres\ndomain types map to Any rather than erroring.Databricks is new. Hostname, port, HTTP path and token are the user-facing parameters; AuthMech=3 and\nUID=token are baked into the URL template so you don’t see them.
Snowflake existed as a twelve-line shell that had never been used in anger, with its JDBC driver commented\nout of the build because the fat jar broke shading. It’s been rebuilt: region is now an optional URL parameter,\nand the thin driver replaces the fat one — no shading problems, no broken native build.
\nNeither platform supports the ON CONFLICT syntax the other drivers use for upserts, so both build a\nMERGE INTO statement instead. That needs something to match existing rows on, so when a primary key column\nisn’t among the written fields — a @GeneratedId key, for instance — the write falls back to a plain\nINSERT and logs a warning. It’s a warning rather than a silent fallback because rows can duplicate under an\n@UpsertOperation when it happens.
Driver-specific column unwrapping moved off the base JDBC invoker onto the driver itself, so Postgres owns its\nPGobject / PgArray handling and any driver returning its own wrapper types can be supported cleanly.
MongoDB connections can now be created and tested from the UI. The driver was already listed in the connections\neditor, but test and create posted nowhere — the UI had no URL mapping for NoSQL connectors and the backend had\nno endpoint. Both now exist, and MongoDB has a health-check provider like the other connectors.
\nA database-backed saved query invoked through a routed HTTP endpoint used to return 200 OK with an empty body\nwhen its connection was undefined or unreachable — indistinguishable from a query that legitimately matched\nnothing.
Connectors now raise typed exceptions whose HTTP status comes from the exception itself:
\n| Condition | Status |
|---|---|
| Schema references an undefined connection | 500 |
| Connection defined but upstream unreachable | 502 |
JDBC connection failures are also reported as trace events, so they show up in the query profile rather than\nvanishing.
\n@DeleteOperation gives you type-safe deletes through TaxiQL. A single @Id renders WHERE pk IN (...),\ncomposite keys use row-value IN, and statements are chunked at 500 rows to stay under Oracle’s IN-list cap.\nValues are always bound, never inlined. The operation returns a deletedCount.
@SqlQuery lets you write the SQL yourself — joins, aggregations, dialect-specific statements — for the cases\nwhere the generated query isn’t what you want. One annotation covers reads and native DML, split by taxi’s\nwrite keyword. Reads map joined and aggregated rows onto plain models by column name or alias, with no\n@Table needed; writes return the affected-row count.
:param placeholders bind as real prepared-statement parameters, validated against the operation’s parameters\nbefore execution. Values never touch the SQL text.
Both were announced in July, and this is the first build\nthey ship in.
\nservices.conf can now downgrade from https to http, which it previously\nrefused to do.You can shape the results of a query directly in TaxiQL — limiting how many rows come back, paginating through\nthem, sorting them, and removing duplicates:
\nfind { Person[]( CountryCode == "GB", orderBy: DateOfBirth desc, offset: 20, limit: 10 ) }limit, offset, orderBy and uniqueBy are the standard database-style controls, and they work on any\nquery, against any source — not just databases.
Sort by more than one field, and paginate:
\nfind { Person[]( orderBy: [CountryCode asc, DateOfBirth desc], offset: 40, limit: 20 ) }They work on projections too, including nested collections, which is handy for trimming child records per\nparent:
\nfind { Customer[] } as { name : CustomerName // Only the 20 most recent transactions per customer transactions : Transaction[]( limit: 20, orderBy: TransactionDate desc )}[]Values can be literals or query parameters, so limit: maxRows works when maxRows is a query argument.
Pushdown is decided per option, per data source. When a source can apply an option itself, Orbital pushes\nthe work down to it; when it can’t, Orbital does it after fetching. Either way you get the same answer, and\npushdown only happens when it can’t change the result — if a source can’t sort, Orbital won’t push a limit\nbelow the missing sort, because limiting before sorting returns the wrong rows.
| Source | Pushed down |
|---|---|
| SQL databases (Postgres, MySQL, MSSQL, Oracle, Redshift, Snowflake, Databricks) | limit, offset, and orderBy when every sort term resolves to a single column — rendered in your driver’s dialect |
| MongoDB | limit, offset and orderBy, as sort / skip / limit |
| Hazelcast | limit, as a key-ordered page |
| REST APIs, Kafka, everything else | Nothing — Orbital applies all of it after fetching |
uniqueBy is never pushed down; it’s always applied by Orbital. Operations annotated with @SqlQuery opt out\nof pushdown entirely, since options can’t be spliced into SQL you wrote by hand — they’re applied after the\nfetch instead.
On streaming queries, limit is supported and completes the stream once it has emitted N items. orderBy,\noffset and uniqueBy are rejected on streams, as is cursor pagination (after / before), which parses but\nis not yet implemented.
This was announced in July — 0.39.1-M1 is the first build it ships in.\nFull detail is in the collection options docs.
\nParameters were being gathered in four separate places that disagreed with each other: the mutation path, the\ngraph-search path, the direct-invocation path, and again inside the invoker. The same call could bind a value\nto the wrong parameter on one path, send null on another, and ignore a declared default entirely on a third.\nAn operation could also be invoked with fewer arguments than it declares, because the graph path caught any\ndiscovery failure and quietly dropped that parameter.
There is now one shared implementation returning an explicit map of parameter to value. Callers differ in what\nthey do when it can’t be satisfied — direct invocation tries another candidate, graph search fails the edge,\nmutation returns a null — but they all gather the same way.
\nThe operation-result cache is keyed off that map, too. Keyed off a set, as it was,\ngetEligibility(orderId=A, lineId=B) and getEligibility(orderId=B, lineId=A) shared a cache entry.
Nullable parameters that can be constructed from context now are. Previously discover short-circuited to null\nthe moment it saw a nullable parameter, so a nullable request body whose fields were all present in context was\nsent as null.
A model whose definition leads back to itself — total : Total = (Total * 1.2), or a pair of types whose\nexpressions reference each other — recursed until the JVM threw StackOverflowError.
A closed loop now yields a null carrying the cycle path — Order.total -> Order.total, or A -> B -> A —\nrather than throwing. Circular definitions are now legible, not valid; they remain unsatisfiable.
This matters more than it looks. StackOverflowError isn’t recoverable the way an exception is: if it lands\nwhile a class is initialising, that class stays unusable for the life of the JVM and every later touch throws\nNoClassDefFoundError. We hit exactly that during a benchmark run — it broke coroutine cancellation\nprocess-wide, with no error naming the cause.
A query like find { GivenName[] }, against a response whose givenNames sit two collection layers deep\ninside the returned object, failed with “no data sources can return GivenName[]”. The query graph only had\nscalar attribute edges, so there was no path.
There’s now an edge from each provided instance to every T[] reachable via a path crossing at least one\ncollection field. Its cost sits between cheap attribute navigation and remote operation invocation, so a direct\nattribute path still wins when one exists, but the planner always prefers in-memory extraction over calling a\nservice again.
A service returning no matching instances yields an empty T[] rather than failing the query.
Several places in the engine caught exceptions and returned a null or an empty result without telling anyone,\nso genuine failures never reached the query error view. Failures that are actually meaningful — a nullable\noperation parameter that couldn’t be constructed, unexpected exceptions while searching for a type — now\npublish to the error stream that feeds the errors websocket and query history.
\nRoutine search backtracking is deliberately left silent. It’s normal control flow, it fires per row during\nprojection, and surfacing it would flood the view with alarming noise.
\nSeparately, fast-failing queries used to tear down their error stream before the UI could connect to it, so the\nsame query would only intermittently show its errors. The error publisher keeps a 30-second replay buffer for\nexactly this reason; eviction is now deferred past the replay window so a late-connecting websocket can still\ndrain it.
\nfind with a\ncontract would be better expressed as a given {}.Either-based\nAPI: deep searches silently dropped all secondary-bag matches whenever the primary bag had any match, merged\ncollections skipped deduplication, and “absent everywhere” was reported as an empty collection rather than a\nnull — which stopped the object builder falling through to discovery. All three are restored.This milestone adds a benchmark suite and CI guards rather than a broad optimisation pass. query-engine-benchmarks\ncarries seeded synthetic schema and data generators, 13 workloads, 7 JMH micro-benchmarks, and a guard suite\nthat gates merge requests on deterministic metrics — operation invocation counts, allocation budgets,\ncomplexity-class scaling ratios and heap-slope leak checks — while tracking wall-clock time as a nightly trend\nrather than a flaky gate.
One fix landed alongside it: fact-bag search caching now validates lazily on read against a generation stamp,\nso adding a fact is O(1) rather than doing predicate work proportional to every cached search. Measured 86–93%\noff addFact, with lookup cost flat.
A full review of the engine’s performance characteristics is written up internally. The remaining findings are\nthe fix programme for subsequent releases, and each has a matching benchmark guard waiting to be switched on.
\nThe navigation has been reorganised:
\n| Was | Now |
|---|---|
| Query editor | Code editor — the new multi-file editor |
| Query history | Activity — running queries and history in one paginated view |
| Authentication | Secrets |
| Stub Servers | Local environments |
| Catalog → Diagram tab | Mesh — promoted to a top-level item |
| — | Copilot |
The endpoint page is now tabbed, matching the catalog layout:
\nA new endpoint, GET /api/schemas/queries/{queryName}/openapi, generates the spec for any saved query by name.\nThe existing /api/q/meta/{queryName}/oas only covered HTTP-routable queries.
Published query URLs shown in the UI now match where the endpoint is actually served — previously the raw\ndeclared URL was shown, which didn’t match the workspace-prefixed route.
\nThree unhappy paths on the Local Environments page used to fail silently or mislead:
\nTwo connection bugs are fixed too. A dropped session (a network blip, or a non-text control frame) used to kill\nthe consumer coroutine permanently: the socket kept reconnecting and logging that it had connected, but nothing\nconsumed the new sessions, so schemas were never resubmitted. And rapid status transitions were being dropped —\nthe in-process HTTP component fires Starting and Running microseconds apart, and the sink was configured to\ndrop an update for every subscriber if any one of them was momentarily at zero demand, leaving consumers stuck\non “starting” forever.
\nProjects that reference NEBULA_* environment variables no longer flash a red config-errors banner at startup\nwhile the local stack is still coming up. Orbital distinguishes “Nebula starting” from a real config failure\nand shows a quiet “Starting local environment…” instead, escalating to a proper error if the connection drops.
The old Angular graph-vis tool is replaced by a React Flow rewrite under tools/graph-debugger. Paste the\ngraph the engine logs while planning a query and explore it interactively to work out why a query isn’t\nresolving.
Large graphs used to lock the canvas, so it now starts empty: add a single type, expand outward from any node\nvia its off-canvas-neighbour badge, or drop the whole graph on at once for small ones. Auto-layout is\nleft-to-right hierarchical, matching the engine’s traversal direction, and dragging a node pins it.
\nbuildHttpHeaders resolved each\n@HttpHeader parameter by its index in the supplied list, assuming that list matched the operation’s\ndeclared parameter order. It doesn’t — directly-provided parameters are appended after searched ones — so\nheader values could silently be attached to the wrong header.ConcurrentModificationException because custom types were being registered\non every load rather than once at class initialisation.java.nio.WatchService doesn’t replay\nevents from before a key is registered, so writing orbital/config/services.conf in one go meant the watcher\nsaw only the orbital/ directory and never the files inside it. Creating a directory now registers the watch\nand walks its existing contents.PROVIDED lineage nodes weren’t showing.Writing these notes turned up a gap in our own record-keeping. 0.36.0 (October 2025) and 0.38.0-M1\n(June 2026) both shipped without a release announcement, and a handful of point releases went out quietly too.\nA fair amount of work reached you without us ever saying so.
\nNone of this is new in 0.39 — it’s all been in your hands for a while. It’s here because you may not know\nyou have it.
\nYou can extend Taxi’s standard library with your own functions, written in Kotlin and loaded at runtime. Declare\nthe function in Taxi, implement it in Kotlin, and it’s available in expressions, projections and queries like\nany built-in.
\nThis is the extension point to reach for when a transformation can’t be expressed in Taxi itself — a\nproprietary check-digit algorithm, a domain-specific parse, an internal encoding scheme.
\nIt’s documented at custom functions; it has simply never appeared in a\nchangelog, because 0.36.0 never got one.
\nIt’s also the mechanism the validation framework will use when user-written validation\nrules land — the loader is already proven.
\n| Feature | Shipped in | Documented |
|---|---|---|
| Scheduled queries — run a query on a cron schedule | 0.36.0 | Yes |
in / not in operators, pushed down to SQL and MongoDB | 0.36.0 | Yes |
MongoDB native aggregations via @MongoAggregate | 0.36.0 | No |
map { } iterates a collection rather than operating on it whole | 0.36.0 | No |
Negate (!) and modulo operators | 0.36.0 | No |
env.conf resolves environment variables inside annotations | 0.36.0 | Partly |
| Query-level Kafka offset override, by annotation | 0.36.0 | Yes |
Custom error responses thrown from a given { } clause | 0.36.0 | No |
| Query error events persisted to the database | 0.36.0 | No |
Roughly twenty stdlib functions — append, average, joinToString, ifEmpty, orEmpty, size, isNullOrEmpty, indexOfItem, containsAll, containsAny, all, some, none, emptyInstance, startsWith, endsWith, matches, containsPattern, padStart, padEnd, applyFormat | 0.36.0 | No |
| Logbook HTTP request/response capture | 0.36.0 | No |
| File-system monitors filter irrelevant files, stopping continuous polling loops | 0.36.7 | n/a |
| WebSocket transport for schema publication | 0.37.0-M4 | Partly |
| Schema-publisher Spring Boot starter | 0.37.0-M4 | Yes |
SOAP as a loadable language via additionalSources | 0.38.0-M1 | Yes |
| XSD as a source format | 0.38.0-M1 | Yes |
JDBC batching — batchSize / batchDuration on database writes | 0.38.0-M1 | Yes |
| Operations usable as callable expressions | 0.38.0-M1 | No |
| Multiple authentication tokens per service | 0.38.0-M1 | Yes |
Environment-specific config files (auth.conf overridden per environment) | 0.38.0-M1 | Partly |
| New query-plan diagram | 0.38.0-M1 | No |
| Tabbed catalog layout, and README as the first tab in the project explorer | 0.38.0-M1 | n/a |
| Endpoint for submitting parameterized query objects | 0.38.0-M1 | No |
| JSON message body accepted on the SSE streaming endpoint | 0.38.0-M1 | No |
| Git configuration changes clean up stale clones | 0.38.0-M1 | n/a |
schema-management relicensed to Apache 2.0 | 0.38.0-M1 | n/a |
The undocumented rows are on our list. If one of them is something you’ve wanted, tell us and we’ll bump it.
\nThis is a milestone build. Try it somewhere that isn’t production first.
\nworkspace-mode toggle rename.Workspaces are opt-in. Leave workspace-mode at None and Orbital behaves as it always has, with a single\nworkspace and legacy routes intact — you can adopt workspaces when you’re ready.
(The post 0.39.1-M1 - Workspaces, Copilot, secrets and validation appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2026-08-24-release-announcement-0.39.0", "title": "0.39.1-M1 - Workspaces, Copilot, secrets and validation", "summary": "The first milestone of 0.39, the biggest change Orbital has had. Multiple workspaces per instance, organisations, a secrets manager with five backends, a data validation framework, an MCP server, and a new multi-file code editor.", "image": "https://orbitalhq.com/changelog-cards/2026-08-24-release-announcement-0.39.0.png", "date_modified": "2026-08-24T00:00:00.000Z", "date_published": "2026-08-24T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2026-07-16-jdbc-deletes-and-native-sql", "content_html": "Available since 0.38.0-M2\nTwo additions to our database connectors in this release: deleting rows through TaxiQL, and running SQL\nyou’ve written yourself.
\nDatabases connected to Orbital have long supported reads, inserts, updates and upserts. Deletes now join\nthe family - annotate a write operation with @DeleteOperation:
@DatabaseService(connection = "customers-database")service CustomerService { @DeleteOperation write operation deleteCustomer(Customer):DeleteResult\n @DeleteOperation write operation deleteCustomers(Customer[]):DeleteResult}Rows are matched on the model’s @Id fields (composite keys work too - rows match on the combination),\nand you can pass a single instance or a whole array. Invoking it looks like any other mutation:
given { customers : Customer[] = [ { id : 123 }, { id : 456 } ]}call CustomerService::deleteCustomersYou get back a deletedCount telling you how many rows went away. Deletes run in a single transaction,\nso a failure partway through rolls the whole thing back rather than leaving you half-deleted.
Orbital’s table operations cover most day-to-day querying, and keep your queries portable across\ndatabases. But sometimes you just want to write the SQL yourself - a join, an aggregation, or something\ndialect-specific. The new @SqlQuery annotation is that escape hatch:
@DatabaseService(connection = "films-database")service FilmStats { @SqlQuery(sql = """ SELECT d.name AS director, COUNT(f.id) AS filmCount FROM film f JOIN director d ON f.director_id = d.id GROUP BY d.name """) operation filmsPerDirector() : DirectorFilmSummary[]}The SQL is passed to your database exactly as written, and result columns map back to your Taxi model’s\nfields by name or alias. One annotation covers both directions: a plain operation runs the SQL as a\nquery, while a write operation runs it as a statement (UPDATE, DELETE, INSERT) and returns the\nnumber of rows affected.
Operation parameters bind into the SQL with the :parameterName syntax:
@SqlQuery(sql = "SELECT title, release_year AS releaseYear FROM film WHERE release_year > :year")operation recentFilms(year : ReleaseYear) : Film[]Values are always bound as prepared-statement parameters - never spliced into the SQL text - so\nuser-supplied values can’t alter your query.
\nBoth features work across all of Orbital’s SQL database connectors. Full details are in the\ndatabase docs, including\nnative query behaviour notes.
(The post Database connectors: delete support and native SQL queries appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2026-07-16-jdbc-deletes-and-native-sql", "title": "Database connectors: delete support and native SQL queries", "summary": "Delete rows through TaxiQL with @DeleteOperation, and run hand-written SQL - joins, aggregations, dialect-specific statements - with @SqlQuery.", "image": "https://orbitalhq.com/changelog-cards/2026-07-16-jdbc-deletes-and-native-sql.png", "date_modified": "2026-07-16T00:00:00.000Z", "date_published": "2026-07-16T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2026-07-04-collection-options", "content_html": "Available since 0.38.0-M2\nYou can now shape the results of a query directly in TaxiQL - limiting how many rows come back, paginating through them,\nsorting them, and removing duplicates. We’re calling these collection options, and they look like this:
\nfind { Person[]( CountryCode == "GB", orderBy: DateOfBirth desc, offset: 20, limit: 10 ) }These are the standard database-style controls we all already know and love - limit, offset, orderBy and\nuniqueBy - but they work on any query, against any source.
When the source can apply an option itself, Orbital pushes the work down to it. When it can’t, Orbital does the work after fetching. Either way you get the same result.
\nSort and take the top N:
\nfind { Film[]( orderBy: RottenTomatoesScore desc, limit: 10 ) }Sort by more than one field, and paginate:
\nfind { Person[]( orderBy: [CountryCode asc, DateOfBirth desc], offset: 40, limit: 20 ) }Options work on projections too, including nested collections - handy for trimming child records per parent:
\nfind { Customer[] } as { name : CustomerName // Only the 20 most recent transactions per customer transactions : Transaction[]( limit: 20, orderBy: TransactionDate desc )}[]Values can be literals or query parameters, so limit: maxRows works just as well when maxRows is a query argument.
For each option, Orbital’s query planner decides - per data source - whether to push it down or to apply it itself.
\nPushing down tot he source system is only permitted if it doesn’t change the answer: if a source can’t sort, Orbital won’t push a\nlimit below the (missing) sort either, because limiting before sorting would hand back the wrong rows.
Here’s what’s supported in this release:
\nlimit, offset and orderBy straight\ninto the generated SQL, in the right dialect for your driver.limit, offset and orderBy into the Mongo query as sort / skip / limit.limit down as a key-ordered page; everything else is applied by Orbital.limit also works on streaming queries, completing the stream once it has emitted N items.
after / before cursors are reserved for cursor-based pagination and will land in a future release - for now they\nparse but are rejected at runtime.
Full details are in the collection options docs, and the syntax reference lives in\nthe Taxi language docs.
(The post Collection options: limit, sort and paginate any query appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2026-07-04-collection-options", "title": "Collection options: limit, sort and paginate any query", "summary": "TaxiQL now supports collection options - limit, offset, orderBy and uniqueBy - pushed down to your data sources where they can be, and applied by Orbital everywhere else.", "image": "https://orbitalhq.com/changelog-cards/2026-07-04-collection-options.png", "date_modified": "2026-07-04T00:00:00.000Z", "date_published": "2026-07-04T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2026-05-08-release-announcement-0.38.0", "content_html": "Queries published as HTTP endpoints can now opt out of authentication on a per-query basis using the new @com.orbitalhq.authentication.AllowAnonymous annotation.
When Orbital is deployed with an authentication provider configured, all published query endpoints require a valid token by default. @AllowAnonymous relaxes that requirement for a single query — useful for health checks, public catalogues, or any endpoint intended to be reachable without a token. Other queries in the same workspace are unaffected.
import taxi.http.HttpOperationimport com.orbitalhq.authentication.AllowAnonymous\n@HttpOperation(url = '/api/q/healthcheck', method = 'GET')@AllowAnonymousquery Healthcheck { find { status: String = "ok" }}The annotation only affects the authentication check. Data policies and authorization rules still run.
\nSee the docs on allowing anonymous access for more detail.
(The post 0.38.0 - Anonymous access for published queries appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2026-05-08-release-announcement-0.38.0", "title": "0.38.0 - Anonymous access for published queries", "summary": "Orbital 0.38.0 - Per-query opt-out from authentication for published HTTP query endpoints", "image": "https://orbitalhq.com/changelog-cards/2026-05-08-release-announcement-0.38.0.png", "date_modified": "2026-05-08T00:00:00.000Z", "date_published": "2026-05-08T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2026-03-24-query-api-content-type-breaking-change", "content_html": "Available since 0.38.x\nAs part of upcoming feature work for improved SDK tooling for JVM and TS/JS ecosystems, there are two\nbreaking changes to the query API are shipping in 0.38.x (and nightly builds of next). Neither affects 0.37.x.
/api/taxiql no longer accepts application/jsonThe /api/taxiql streaming query endpoint previously accepted requests with Content-Type: application/json.\nThis is no longer supported.
Use either of the following content types instead:
\napplication/taxiql (Preferred, but less standard)text/plain (Standard, but less accurate)Either are fine to use, and both content types are already supported in all versions of Orbital today, so you can make this change now, without waiting.
\nIf you’re sending queries via curl or an HTTP client, update accordingly:
# Before (no longer works)curl -X POST /api/taxiql \\ -H "Content-Type: application/json" \\ -d '{ "query": "find { ... }" }'\n# Aftercurl -X POST /api/taxiql \\ -H "Content-Type: application/taxiql" \\ --data-raw 'find { ... }'/api/vyneqlThe legacy /api/vyneql endpoint has been removed. It was a holdover from the previous product name and has been\nsuperseded by /api/taxiql for some time. If you were still referencing /api/vyneql, update your calls to use /api/taxiql.
(The post Breaking change: /api/taxiql content-type and removal of /api/vyneql appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2026-03-24-query-api-content-type-breaking-change", "title": "Breaking change: /api/taxiql content-type and removal of /api/vyneql", "summary": "The /api/taxiql endpoint no longer accepts application/json. The legacy /api/vyneql endpoint has been removed.", "image": "https://orbitalhq.com/changelog-cards/2026-03-24-query-api-content-type-breaking-change.png", "date_modified": "2026-03-24T00:00:00.000Z", "date_published": "2026-03-24T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2026-03-23-release-announcement-0.37.0-M3", "content_html": "Orbital 0.37.0-M3 is the third milestone release of 0.37.\nWe haven’t published release notes on 0.37.0-M1 or -M2, we’ll cover off those releases too.
The headline features are a new parseJson() standard library function, the ability to export query history\nas Preflight test specs, and a significant improvement to observability — with request\nparameters now captured on every remote call across all connectors.
There’s also a crop of reliability improvements: better git sync resilience, a fix for a stack overflow in\nthe query engine, and an internal overhaul that removes a class of thread-pool starvation under concurrent load.
\nAs a milestone release, 0.37.0-M3 is intended for early adopters and teams that want to test ahead of the\nGA release. Feedback welcome.
\nparseJson() stdlib functionYou can now use parseJson() in your queries and projections to parse a JSON string into a typed value.
This is useful when JSON arrives embedded in a field as a string — a common pattern in event-driven systems where a\nmessage envelope wraps a serialized payload.
\nQuery history can now be exported as a Preflight test spec, in addition to the\nexisting ZIP regression pack format.
\nWhen downloading a regression pack from query history, you can now choose between Zip (the original format)\nand Preflight spec files.
Preflight Spec Files are markdown files that describe a test scenario,\nalong with all the information to stub out query services:
\n---spec-version: 0.1--- # Test name Optional description paragraph. ## Query ```taxiqlfind { Customer( CustomerId == "C-100" ) } as CustomerProfile``` ## Data Sources ### Customer API<!-- operation: getCustomer --> Response:```json{ "id": "C-100", "name": "Alice Smith", "age": 30 }``` ## Expected Result ```json{ "id": "C-100", "name": "Alice Smith", "age": 30, "isAdult": true }```By capturing these using the data from your queries, you can very quickly build test suites for\nyour taxi projects.
\nPreflight tests are runnable using Gradle, so works great with established build tooling and CI/CD.
\nThe capture of input parameters for events shown in the Trace View has been extended, capturing inputs across all connectors.
\nOrbital now supports capturing Java Flight Recorder traces for capturing diagnostic data.\nThis feature is disabled by default, but can be enabled through configuration
\n0.37.0-M3 extends this to further capture exception data.
Fixed a bug where an operation whose return type also appeared as an input parameter type would trigger\nrecursive parameter construction, ultimately causing a stack overflow. Type-level cycle detection is now\napplied during object building, so these circular type graphs are handled cleanly.
\nA git repository sync failure at startup is now treated as a warning rather than an error. If a\nlocally-cached copy of the schema is available, Orbital will use it and continue running — reporting a\nWARNING state in the UI rather than refusing to start.
The UI also now distinguishes between ERROR (schema could not be loaded at all) and WARNING (schema\nloaded from local cache), with separate alerts and colour-coded severity badges, so it’s clearer what’s\nactually happening.
A rate limiter (via resilience4j) has also been introduced on git repository polling, to prevent remote\ngit servers from denying requests when Orbital is polling frequently.
\nThe internal TaxiQL query engine has been refactored to remove blocking calls. Under specific conditions, it was\npreviously possible for the query engine to get into thread starvation, waiting for I/O calls to complete.
\nBy migrating the core query engine away from blocking, this removes the risk
(The post 0.37.0-M3 - Preflight exports, parseJson, and observability improvements appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2026-03-23-release-announcement-0.37.0-M3", "title": "0.37.0-M3 - Preflight exports, parseJson, and observability improvements", "summary": "Orbital 0.37.0-M3 - Preflight test spec exports, parseJson stdlib function, improved query observability, and performance improvements", "image": "https://orbitalhq.com/changelog-cards/2026-03-23-release-announcement-0.37.0-M3.png", "date_modified": "2026-03-23T00:00:00.000Z", "date_published": "2026-03-23T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2026-02-16-release-announcement-0.36.6", "content_html": "Orbital 0.36.6 introduces enhanced authentication capabilities for complex service integration scenarios.
\nauth.confauthenticationTokens { "com.foo.service.*" [ { type: HttpHeader, value: ${API_KEY}, headerName: X-API-KEY }, { type: QueryParam, parameterName: apiKey, value: ${API_SECRET} } ]}There are no other functional changes in this release.
(The post 0.36.6 released appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2026-02-16-release-announcement-0.36.6", "title": "0.36.6 released", "summary": "Orbital 0.36.6 introduces enhanced authentication capabilities for complex service integration scenarios.", "image": "https://orbitalhq.com/changelog-cards/2026-02-16-release-announcement-0.36.6.png", "date_modified": "2026-02-16T00:00:00.000Z", "date_published": "2026-02-16T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2026-02-13-release-announcement-0.36.5", "content_html": "Orbital 0.36.5 is a patch release that updates the Taxi compiler dependency to fix enum-related compilation errors.
\nThere are no other functional changes in this release.
(The post 0.36.5 released appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2026-02-13-release-announcement-0.36.5", "title": "0.36.5 released", "summary": "Orbital 0.36.5 is a patch release that updates the Taxi compiler dependency to fix enum-related compilation errors.", "image": "https://orbitalhq.com/changelog-cards/2026-02-13-release-announcement-0.36.5.png", "date_modified": "2026-02-13T00:00:00.000Z", "date_published": "2026-02-13T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2026-01-08-release-announcement-0.36.4", "content_html": "Orbital 0.36.4 introduces a new debugging feature for advanced troubleshooting.
\nThere are no other functional changes in this release.
(The post 0.36.4 released appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2026-01-08-release-announcement-0.36.4", "title": "0.36.4 released", "summary": "Orbital 0.36.4 introduces a new debugging feature for advanced troubleshooting.", "image": "https://orbitalhq.com/changelog-cards/2026-01-08-release-announcement-0.36.4.png", "date_modified": "2026-01-08T00:00:00.000Z", "date_published": "2026-01-08T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2025-12-22-release-announcement-0.36.3", "content_html": "Orbital 0.36.3 is a patch release that addresses issues with very large lineage records.
\nThere are no other functional changes in this release.
(The post 0.36.3 released appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2025-12-22-release-announcement-0.36.3", "title": "0.36.3 released", "summary": "Orbital 0.36.3 is a patch release that addresses issues with very large lineage records.", "image": "https://orbitalhq.com/changelog-cards/2025-12-22-release-announcement-0.36.3.png", "date_modified": "2025-12-22T00:00:00.000Z", "date_published": "2025-12-22T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2025-12-05-changes-to-start-and-default-config", "content_html": "We’ve made some small changes on how to get Orbital running. We’ve also added a new config variable to centralize\nwhere Orbital stores all it’s internal files. You should add this config variable to your own deployments before 0.37 is released.
\nWe’ve updated the way people get started on Orbital - replacing our docker-compose.yml with a bash script.
\nIf you head over to orbitalhq.com, you’ll notice that we’re now asking people to start\nby curling:
\ncurl -sSL https://start.orbitalhq.com/start.sh | bashYou can view the bash script - it’s still running the same docker-compose.yml,\nbut we’ve just added some scripting to make the experience a bit better.
\nThere’s very little that’s changed.
\nYou should add --vyne.app.data.path=/a/path/for/your/config to your config. It’s safe to do this now, before 0.37.0 is released.
It’s also safe not to do this at all, and Orbital will work with reasonable defaults. But, our new preferred config includes setting this property.
\n--vyne.app.data.path)We still ❤️ Docker Compose - it’s our preferred way for people to start the stack. But, we hit issues that made the experience unpleasant for developers…
\nWhen you’re working with Orbital, we expect you’ll do some stuff inside the browser, and other stuff inside your IDE.
\nHowever, if Docker creates the directories you’re using - even if your docker container is running with a non-root user, then you can end up\nwith file permissions errors. You - the user - lack the permissions to edit the files that get created.
\nThe start.sh fixes this by simply creating the directories before docker launches,
Telling Docker Compose to launch in a non-root user is slightly trickier than you’d expect. It’s not hard, but you can’t\nsay “run with my account”, you have to say “run with this account”.
\nThe idiomatic way to address this is:
\nservices: orbital: image: orbitalhq/orbital:${ORBITAL_VERSION:-next} user: "${UID}:${GID}"And then have a .env file that defines those variables:
UID=1000GID=1000This isn’t difficult, but it’s awkward for a user to just get started. So, the script handles this for you.
\nOrbital is an integration platform, so when we ship demos or test stacks, we need things to integrate.
\nWe solved that by building Nebula to deploy local environments. However,\nNebula deploys other docker containers - and docker-launching-docker varies between OS’s. That meant our docker-compose.yml\nis OS-specific. We built tools to detect and try to serve the correct docker-compose.yml, but it’s clumsy if you’re running from the command line.
\nOur script detects which OS you’re running on, and downloads the correct docker-compose file for you.
\nThat it! The new launcher script is live now, and config variables are shipping now in next and will be part of the 0.37 release.
Happy integrating.
(The post New start script, and changes to default config appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2025-12-05-changes-to-start-and-default-config", "title": "New start script, and changes to default config", "summary": "We’ve made some small changes on how to get Orbital running. We’ve also added a new config variable to centralize where Orbital stores all it’s internal files. You should add this config variable to your own deployments before 0.37 is released.", "image": "https://orbitalhq.com/changelog-cards/2025-12-05-changes-to-start-and-default-config.png", "date_modified": "2025-12-05T00:00:00.000Z", "date_published": "2025-12-05T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2025-12-02-release-announcement-0.36.2", "content_html": "Orbital 0.36.2 is a patch release that fixes a critical issue with lineage persistence.
\nThere are no other functional changes in this release.
(The post 0.36.2 released appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2025-12-02-release-announcement-0.36.2", "title": "0.36.2 released", "summary": "Orbital 0.36.2 is a patch release that fixes a critical issue with lineage persistence.", "image": "https://orbitalhq.com/changelog-cards/2025-12-02-release-announcement-0.36.2.png", "date_modified": "2025-12-02T00:00:00.000Z", "date_published": "2025-12-02T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2025-11-11-release-announcement-0.36.1", "content_html": "Orbital 0.36.1 is a patch release that addresses memory leaks.
\nThere are no other functional changes in this release.
(The post 0.36.1 released appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2025-11-11-release-announcement-0.36.1", "title": "0.36.1 released", "summary": "Orbital 0.36.1 is a patch release that addresses memory leaks.", "image": "https://orbitalhq.com/changelog-cards/2025-11-11-release-announcement-0.36.1.png", "date_modified": "2025-11-11T00:00:00.000Z", "date_published": "2025-11-11T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2025-08-04-improved-array-type-checking", "content_html": "Orbital 0.36 introduces a fix to type checking with array arguments.
\nPreviously, arrays were not being correctly type checked, such that this was possible:
\nThe same type checking would also fail with arguments to functions or expression types:
\nThese now correctly return compilation errors.
\nThis is a breaking change, as these statements did not used to return compilation errors (but would not behave as expected).
\nThis change will be released in 0.36, and is available from 0.36.0-M9
(The post Breaking change - improved type checking with arrays in 0.36 appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2025-08-04-improved-array-type-checking", "title": "Breaking change - improved type checking with arrays in 0.36", "summary": "Orbital 0.36 introduces a fix to type checking with array arguments.", "image": "https://orbitalhq.com/changelog-cards/2025-08-04-improved-array-type-checking.png", "date_modified": "2025-08-04T00:00:00.000Z", "date_published": "2025-08-04T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2025-05-07-release-announcement-0-35-0", "content_html": "Orbital 0.35.0 brings significant enhancements to core capabilities, with major improvements to streaming,\ncaching, and model handling.
\nThis release focuses on stability and performance, particularly for high-volume data processing scenarios.
\nPartial models create variations of existing models where all fields are optional. This pattern is especially useful for API operations that support partial updates (PATCH), allowing clients to send only the fields they want to change.
\nmodel Customer { id: CustomerId inherits String name: CustomerName inherits String} // Creates a new model where all fields are optionalpartial model CustomerUpdate from CustomerWhen you create a partial model, all fields become optional (nullable), including:
\nclosedThis all combines well with the @OmitNulls annotation to ensure null fields are excluded from serialized payloads:
\n// Original model with required fieldsmodel Product { id: ProductId inherits String name: ProductName inherits String price: Price inherits Decimal category: Category tags: Tag[]}\n// Create a partial version where everything is optional@OmitNullspartial model ProductUpdate from Product\nservice ProductCatalog { // Full replacement (PUT) write operation replaceProduct(Product): Product // Partial update (PATCH) write operation updateProduct(ProductUpdate): Product}We now support including OpenAPI, Avro and Protobuf files directly within a taxi project.
\nAdd entries in the additionalSources block of your taxi.conf, as shown below:
name: taxi/mixed-sourcesversion: 0.3.0sourceRoot: src/additionalSources: { "@orbital/avro" = "avro/src/*.avsc" "@orbital/openapi" = "openapi/*.yaml" "@orbital/protobuf" = "proto/src/**/*.proto"}These sources are automatically read, along with their taxi annotations, and imported into your taxi project.
\nThis simplifies setups (and startup times) for teams where each spec was previously imported as standalone projects.
\nWhen running Orbital in a cluster, background stream jobs can now be configured to run in parallel,\nwhich controls the number of nodes in the cluster that will execute the stream.
\nusing the @Parallel annotation.
For example, assuming Orbital is deployed in a 6-node cluster, consuming events from Kafka.
\nimport com.orbitalhq.streams.Parallel @Parallel(count = 4)query MyStream { stream { CustomerLoggedInEvent } call MyMongoDb::upsertCustomerMetrics}In this configuration, 4 of the nodes will subscribe to Kafka, and consume the events.
\nOrbital correctly rebalances as nodes enter and leave the cluster.
\nLearn more in the streaming data docs
\nThe @com.orbitalhq.caching.Cache annotation offers control over caching behavior at both operation and model\nlevels.
You can disable caching for specific operations or data types, or adjust cache expiration\nwith configurable time-to-live settings.
\nThis helps balance performance needs when working with both static reference data and\nchanging values in long-running stream processors.
\nRead more about configuring caching in the caching docs
\nWe added support for Azure Service Bus, enabling integration with Azure messaging infrastructure\nthrough a full-featured connector.
\nRead more in the Azure Service Bus docs
\n@HttpRetry annotation. [ORB-931](The post Orbital 0.35 - Partial models, mixed-source projects, parallel streaming, improved caching appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2025-05-07-release-announcement-0-35-0", "title": "Orbital 0.35 - Partial models, mixed-source projects, parallel streaming, improved caching", "summary": "Orbital 0.35 - Partial models, mixed-source projects, parallel streaming, improved caching", "image": "https://orbitalhq.com/assets/title-card-DCtABlAo.jpg", "date_modified": "2025-05-07T00:00:00.000Z", "date_published": "2025-05-07T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2024-07-24-release-announcement-0-33-0", "content_html": "![\"\"/](\"https://orbitalhq.com/assets/0-33-title-card-Gjg5NP06.jpg\")
Orbital 0.33 is out - with lots (and lots) of small, incremental improvements to the features you already know and love.
\nSure, we skipped 0.32 - but who hasn’t had an episode in early 30’s they forgot?
\nBecause this release is all about beloved features growing, and squashing bug fixes, and because we made a\nbold choice shortly after Dry January finished to name each of this year’s releases after an 80’s sitcom,\nwe’re proud to present Orbital 0.33 - The Growing Pains edition.
\nWe’ve completely redesigned the landing page and now surface insights into the health of your project’s connections,\nan at a glance overview of schema changes, as well as metrics on currently running services.
\nWe’ll be adding more content in this area as well, to help get new users up to speed,\nand provide more experienced users with documentation and tutorials to improve their Orbital productivity. Watch this space!
\nYou asked for it, and we listened - tabs are now part of the query editor experience!
\n![\"Tabs](\"https://orbitalhq.com/assets/query-editor-BwUgCj7Y.png\")
Create as many queries as you like, safe in the knowledge that you can tweak and edit them in isolation,\nand run the query when you’re satisfied things are looking good.
\nResults are retained for each tab, allowing some serious multitasking.
\nWe’ve also overhauled the query editor’s toolbar, allowing you to publish queries to endpoints, and remove them\nif they’ve already been published. Alongside that, you’re now able to see which queries have endpoints associated with them, launch the endpoint,\nor copy the endpoint URL or code for a cURL command.
\nWe’re confident these UI additions further improve the developer experience, let us know what other improvements in this space you’d like to see.
\nThe Stream Server historically was a standalone service that was responsible for executing long-running streaming queries.
\nIt’s now folded directly into Orbital, simplifying the deployment significantly.
\nOur S3 connector received a much-needed makeover.
\nWhen reading, we now support reading from either a single file, an entire bucket, or any type of wildcard glob pattern. Files on S3 are also now supported as a standard write target.
\nWe also support reading and writing to S3 in any of Orbital’s supported formats.
\nThis means you can now do things like query a database, enrich it against a series of APIs, and write the results to a csv file on an S3 bucket. Alternatively, you can read a CSV file from S3, split it, enrich each record and write the values to Kafka.
\nFor example:
\n// Given a model of data stored on S3:@Csvmodel TradeSummary { symbol : Symbol inherits String open : OpenPrice inherits Decimal high : HighPrice inherits Decimal close : ClosePrice inherits Decimal}\n// Expose the S3 bucket:@S3Service(connectionName = "MyAwsConnection")service AwsBucketService { @S3Operation(bucket = "MyTrades") operation readBucket(filename:FilenamePattern = "trades.csv"):TradeSummary[]}\n// Expose some enrichment services:service TradeVolumeApi { @HttpOperation(url="https://myTradeService/volumes/{symbol}", method = "GET") operation getTradeVolumes(@PathVariable("symbol") symbol : Symbol): TradeVolumes}\n// Expose our enriched data model:model TradesWithVolumes { symbol : Symbol prices : { open : OpenPrice close : ClosePrice } volumes : { volumes : TradeVolumes }}\n// And a Kafka topic to write to:service MyKafkaBroker { @KafkaOperation(topic = "tradesWithVolumes") write operation publishTrades(TradesWithVolumes):TradesWithVolumes}\n// Given the above, we can fetch from S3, transform against our// enrichment API, and write the results to Kafka using the following// query:find { TradeSummary[] )call MyKafkaBroker::publishTradesSee more examples in the docs for the S3 connector.
\nYou can now access the message key for a Kafka message directly in your model:
\nimport com.orbitalhq.kafka.KafkaMessageKey\nmodel Movie { // The key from Kafka will be read into the id property @KafkaMessageKey id : MovieId inherits String title : Title inherits String}Similarly, Kafka message headers can now be provided using the @KafkaMessageMetadata annotation
\nMore details are available in the updated Kafka documentation
\nOrbital has supported saved streaming queries for some time. These run in the background doing things like consuming from\na Kafka topic (amongst others), transforming, enriching and writing data.
\nNow, these same queries can be observed via HTTP endpoints - using either Server Sent Events or Websockets. Simply add an annotation to your query definition:
\n@HttpOperation(url = '/api/q/newReleases', method = 'GET')query getNewReleaseAnnouncements { stream { NewReleaseAnnouncement } as { title : MovieTitle reviewScore : ReviewScore }[]}These annotations can also be added by using the new publish endpoint feature detailed in the query editor improvements
\nThis query would be available over Curl using
\ncurl -X GET 'http://localhost:9022/api/q/newReleases' \\ -H 'Accept: text/event-stream;charset-UTF-8'More details are available in the documentation for saved streaming queries.
\nWe’ve added support for Avro as a format - both reading and writing.
\nAdditionally, we also support Confluent’s own, special, magical version of Avro, which injects a few additional bytes at\nthe start … “magic bytes” — their words, not ours. Anyway, we support reading this, without a dependency on the Confluent schema server.
\nFind out more about Avro support in the Avro documentation
\nOrbital can now batch upserts target to a Mongo Collections. See the documentation for details.
\nPreviously, mutations were run incrementally in parallel.
\nYou can now optionally indicate that a mutation should be performed at the end of the query,\nafter all projections have been completed. This is useful for targets like S3, where incremental writing isn’t supported.
\nMore information and examples are available in our updated docs on mutations.
\nThere’s been a number of performance improvements across the stack:
\nSome customers like to manually deploy their taxi projects onto the same box that Orbital is running on, and refer to the taxi projects using file paths (rather than pulling from a git repository).
\nIn cases like this, it’s often convenient to declare your projects in workspace.conf with relative paths (relative to the workspace.conf file), rather than absolute paths. We’ve fixed a number of bugs that previously made this very hit-and-miss. Now, it’s all hits.
\nPreviously, we only showed the first 100 results in query history. We now paginate these, so the full result set is available.
\nWe fixed a number of issues with websockets timing out - this was particularly noticeable if Orbital was deployed in AWS behind an ALB, where the ALB would terminate websocket connections after a period of inactivity. We’ve added ping/pong on the websockets to prevent this.
\nOften, a microservice will publish it’s project directly to Orbital. Previously, these weren’t removable using the UI. Now they are. That’s progress.
\nThis used to throw an error. Now it doesn’t.
\nfind { long: Long by (Long) Foo}This also used to throw an error. We fixed that too.
\nfind { FilmCatalog } as (films:Film[]) -> Movie[]We squashed lots of bugs related to workspaces that were pulled from git, and projects within workspaces that were pulled from git.\nThis now behaves much much better.
\nWe have fixed an SQS subscription that might result in corresponding poll operations interrupted after the first successful poll.\nAdditional configuration parameters to fine tune AWS SQS poll operations were also added, see the docs for the details.
\nThis bug manifested in lots of little, but rather annoying changes.
\nWe now automatically update the UI after changes are made to the workspace.conf file (such as adding and removing projects).
\n(The post Orbital 0.33 - Landing page insights, improved query editor, and simpler deployments. appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2024-07-24-release-announcement-0-33-0", "title": "Orbital 0.33 - Landing page insights, improved query editor, and simpler deployments.", "summary": "Orbital 0.33 - Landing page insights, improved query editor, and simpler deployments.", "image": "https://orbitalhq.com/assets/0-33-title-card-Gjg5NP06.jpg", "date_modified": "2024-07-24T00:00:00.000Z", "date_published": "2024-07-24T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2024-04-05-release-announcement-0-31-0", "content_html": "![\"\"/](\"https://orbitalhq.com/assets/0-31-title-card-BI6HYHTz.jpg\")
We’re excited\nto announce the release of Orbital 0.31.0 -\nwith a large focus on helping new users feel comfortable — which reminded us of a certain ’80s friend.\nSo, we present Orbital 0.31.0 - The “Alf” edition. 👽🛸🏡
\nWe now support MongoDB as a datasource, including support for both\nquerying and writing
\nBuilding on top of our support for Hazelcast as a cache,\nHazelcast is now available as a data source, supporting reads, writes and streams.
\nUse a Hazelcast Map as a high speed data store,\nor use a Map as the basis for a Stream of data,\ngiving you the best of both worlds.
\nFor those wanting to dip their toes into the world of Taxi and Orbital, we’ve built an onboarding flow which should help\nget you up to speed in no time! And remember, just like Alf trying to fit in with the Tanners, you might feel a bit out\nof place at first, but with our guidance, you’ll be navigating through like a pro in no time!
\nYou’ll see this screen automatically when you don’t have any data sources declared, but you can also view it manually by\ngoing to /onboarding.
\n![\"The](\"https://orbitalhq.com/assets/onboarding-BYhHAFME.png\")
We welcome feedback in this area of the app, so please take it for a spin and let us know what you think.
\nNow that you’re familiar with adding projects and data sources after completing the onboarding steps, you’ll be happy to\nhear that those same project import and data source creation steps are available to you outside the onboarding flow.\nConsistency FTW!
\nWe’ve completely reworked the Connections page, allowing a more streamlined view of all connections, and their related\ndata sources.
\n![\"Viewing](\"https://orbitalhq.com/assets/data-source-tree-CDMdKcSQ.jpg\")
If you want to add a new data source, then the same flow that was created for the onboarding flow is now used here as\nwell. It’s like having Alf in charge of the kitchen - he sticks to his recipes with that good ‘ol fashioned consistency\nthat we’re all about here at the house of Orbital.
\n![\"Adding](\"https://orbitalhq.com/assets/add-data-source-y6jRubvj.jpg\")
Ever needed a few more cm’s of screen space and thought, gee that sidebar is taking up a bunch of space? Well, now you\ncan collapse it with a click of the mouse, and regain all that space you’ve been desperately hankering for. We’ll\nremember your preference as well, and restore things how you left them.
\n![\"Optimise](\"https://orbitalhq.com/assets/sidebar-collapse-DRpusLhj.png\")
By popular demand, one of our most requested features is the ability to control which services are called in a query.\nAfter all - if Alf taught us anything - given a universe of possibilities, a little navigation can save you landing in a whole world of trouble.
\nWhile designing this feature, we wanted to ensure that Taxi remains declarative - and find a balance between giving\nusers control over which services are called, while remaining resilient and self-adapting as services evolve.
\nYou can now limit a query to only call specified services, with the using keyword:
find { Film[] } as { filmId : FilmId reviews : ReviewScore}using { FilmsDb, NetflixApi::getReviews }The list of allowed endpoints can be a mixture of services (FilmsDb), or even specific operations on services\n(NetflixApi::getReviews).
Similarly, you can allow Orbital to call any services except some, using the excluding keyword:
find { Film[] } as { filmId : FilmId reviews : ReviewScore}excluding { ImdbApi, RottenTomatoes::getReviews }This too allows combining services and specific operations to exclude.
\nThis feature is considered in preview, and the syntax may change, so we’re actively seeking feedback.
\nPlease reach out to share your thoughts.
\nWe’ve added new support for filtering streams of data server-side (ie., on Orbital).
\nImagine you have a Kafka stream of stock quotes, and you only want\nquotes for a specific symbol - this is now possible using .filterEach().
stream { StockQuotes.filterEach( Symbol -> Symbol == 'AAPL' ) }We now display HTTP headers in the Profiler view of queries
\n![\"Http](\"https://orbitalhq.com/assets/http-headers-display-oVdy6yEf.png\")
The Endpoints page now shows the current status of individual streams.
\nThe Stream Page allows enabling & disabling of individual streams.
\n![\"Stream](\"https://orbitalhq.com/assets/stream-server-overview-DI-hnKF7.png\")
When a stream appears for the first time in the schema, it’s now disabled by default, and required\nmanually enabling — for the first time only.
\nThis is to prevent streams - which can be mutating - starting accidentally, because as Alf would say, ‘Hey, no one wants\naccidental mutations on their hands… or their planet!
\nWhenever changes are found in a running streaming query, the stream\nis now automatically updated. Previously, this was buggy…Suboptimal.
\nThis build bumps our internal dependencies, addressing the following CVE’s:
\n(The post 0.31 released - Hazelcast, MongoDb and a new onboarding experience appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2024-04-05-release-announcement-0-31-0", "title": "0.31 released - Hazelcast, MongoDb and a new onboarding experience", "summary": "Orbital 0.31.0 - \"Alf\" - MongoDB support, Hazelcast datasources and onboarding", "image": "https://orbitalhq.com/assets/0-31-title-card-BI6HYHTz.jpg", "date_modified": "2024-04-05T00:00:00.000Z", "date_published": "2024-04-05T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2024-03-08-release-announcement-0-30-0", "content_html": "![\"\"/](\"https://orbitalhq.com/assets/0-30-title-card-BWp82QFu.jpg\")
We’re excited to announce the release of Orbital 0.30.0 - our “Full House” edition, because we got so distracted by Valentine’s Day last month that we didn’t manage to ship a release, making this one double-packed.
\nIf you’re not familiar with Orbital, it’s a platform for automating integration between APIs, Databases, Message Brokers, Serverless Functions, and more.\nWe have great stuff like API-spec driven data sources, self-repairing integration, automated lineage and more.
\nSo, let’s take a look at what we’ve been working on for the past two months.\nIt’s a full house jam packed with features and squashed bugs.
\nWe’ve extended our family of supported databases to include MS SQL Server for comprehensive read and write operations.
\nSo, it’s “DATABASES!\nDATABASES!\nDATABASES!”, sweaty armpits, and happy Microsoft shops.
\nOur docs explain all the details on how to connect to MSSQL, to get your Northwind blowing.\n(Get it? That’s a MSSQL sample database joke. If you know, you know.)
\n![\"Steve](\"https://media1.tenor.com/m/eIJUpOJlykUAAAAC/steve-ballmer-yes.gif\")
Someone paid us a lot of money to build SAML. We didn’t wanna do it. But we did, and now it’s awesome. Learn more about how to configure SAML authentication in Orbital.
\nMutual trust is a big theme in the Tanner household, and it’s something we can really get behind.
\nmTLS is now supported when calling HTTP(s) APIs. Read more about how to set up mTLS
\nOrbital will now read an XML message with a JSON message in the middle, or JSON with XML in it, or a CSV file with a JSON blog in that, or really anything inside of another thing, which is inside yet another thing.\nIt’s the integration version of a Turducken.
\nFor example, here’s some XML inside a JSON message:
\n{ "messageId" : "123", "xmlRecord" : "<person><name>Jimmy</name></person>"}Here’s the associated definition:
\nimport com.orbitalhq.formats.Xmlmodel MyMessage { messageId : MessageId inherits String xmlRecord : Person}\n@Xmlmodel Person { name : PersonName inherits String}You can now pass the claims from a JWT token into Orbital so the claims can be used during query execution,\nand passed to upstream services.
\nLet’s look at a simple example where your JWT token has a key piece of information - the customers accountId.\nIf you want to use these to connect with external REST services to run specific Orbital queries, the first thing to do is create a model that\nbuilds on Orbital’s basic JwtClaim model:
// Custom JwtClaim model with contactId and accountIdmodel CompanyXJwtClaim inherits JwtClaim { accountId: AccountId // a claim present with the key accountId // other claims omitted}Adding this model to your system makes sure that accountId is available for Orbital when it runs queries.
For example, a service may require the users accountId from the JWT be passed in the URL:
// A service needs to use the current users accountId in the URL: service AccountService { @HttpOperation(method = "GET",url = "/account/{accountId}") operation getByAccountId(@PathVariable("accountId") accountId: AccountId): Account}To make the users accountId available, we simply expose the JWT to the query:
query MyQuery ( jwt:CompanyXJwtClaim ) { given { jwt } find { Account }}That’s it! The presented JWT is read and the accountId is used to invoice the getByAccountId operation.
Previously, it was hard to see when things went wrong inside streaming queries, requiring tailing logs to debug issues.
\nNow, errors in streams are shown in a dedicated UI.
\n![\"Errors](\"https://orbitalhq.com/assets/query-problems-panel-B4zmnzDG.gif\")
Results returned from the server can be filtered client side in the query view:
\n![\"Filtering](\"https://orbitalhq.com/assets/filters-BDk6t8Vl.gif\")
We’ve enabled Taxi’s type checker by default, to help surface errors in queries earlier.
\nFor example, everyone in our office has made this mistake before:
\nfind { Film[] } as { cast: (Actor[]) -> { // because this is projecting an array... name : ActorName } // <--- ...this should be an array} // <-- so should thisNow, the compiler tells us what a mistake it was, so we can take a good long look at ourselves.
\nWhen projecting, you sometimes need to hoist multiple variables into the scope. This is to make them available at the top level of a projection, without declaring them directly in the output.
\nFor example, in the below example, we want to operate on a single item from an array of values, as well as the parent object.
\nHowever, we need both the objects in scope:
\nfind { Film } as (Film, first(Actor[])) -> { // two values declared in scope title : Title // title comes from Film starring : ActorName // ActorName comes from Actor}Our query syntax now supports adding these additional variables into the query scope
\nclosedMarking a model as closed in TaxiQL indicates that the query engine should not attempt to build an instance if you ask for it.
Generally, this is the expected behaviour for things that a server returns.
\nFor example:
\n// I want the Film object as returned from the server, not constructedmodel Film { title : Title inherits String}\nservice Films { operation findAllFilms():Film[]}If writing a query like:
\nfind { Film[] }In the above example, you don’t want Orbital to try to construct a Film instance, you want one returned.
\nIf you forget to mark Film as closed then the compiler will now warn you.
// That's better:closed model Film { title : Title inherits String}Here’s a big long list of things that we showed to people who asked why we hadn’t been to the pub this month.
\nTo play us out, while you read through our bug list, here’s the Full House theme song.
\n\ngiven clause with cast statement referencing parameter throws exception(The post 0.30 is Out - SQL Server, new authentication methods, and JSON inside XML inside a... duck? appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2024-03-08-release-announcement-0-30-0", "title": "0.30 is Out - SQL Server, new authentication methods, and JSON inside XML inside a... duck?", "summary": "Orbital 0.30.0 - \"Full House\" - MSSQL, SAML, mTLS and Mixed Messages", "image": "https://orbitalhq.com/assets/0-30-title-card-BWp82QFu.jpg", "date_modified": "2024-03-08T00:00:00.000Z", "date_published": "2024-03-08T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2024-01-27-release-announcement-0-27-0", "content_html": "![\"\"/](\"https://orbitalhq.com/assets/title-card-i06M7AW0.jpg\")
As the Orbital office farewells Dry January, we welcome back Friday drinks with a fresh release - 0.27.0.
\nPull up a stool, grab your favorite beverage, and let’s toast to the new features, usability improvements, and fixes that are making Orbital 0.27.0 as cozy and welcoming as your favorite Boston bar.
\nLike Sam Malone behind the bar - or a Fraser reboot - we know the importance of second and third chances.
\nThat’s why we’ve introduced @Retry annotations, ensuring that if at first you don’t succeed, requests can try, try again to connect and get your data flowing just right.\nRead more about it in the release announcement here, and the docs are available here
There’s nothing worse than overstaying your welcome when it’s time to leave.
\nOrbital’s caches now support Cache headers, evicting data when it’s stale.\nRead more about it here, with the docs available here
\nOur Kafka connections now have more options than Frasier had patients - with full support for secure Kafka connections.\nExpect a seamless experience that keeps the data pouring in. More detail available in our docs
\nPobody’s Nerfect, right?
\nOrbital now displays compilation errors in a slightly less antagonistic way. Read more here.
\nRunning a new query now refreshes the history view automatically, much like Norm Peterson’s beer mug. You’ll always have the latest information at your fingertips, no manual refresh needed.
\nOur loading bars have received a makeover, becoming more informative and visually appealing. It’s the little details that make all the difference, ensuring you’re not left hanging while waiting for your data to appear.
\nProjections of Nested Arrays: We’ve fixed the projection of nested arrays, ensuring that your data structures are handled with the care and precision of Cliff Clavin’s factoids—accurate, detailed, and meticulously organized.
\nNested Values in Discovery: Nested values are now correctly used as inputs to discovery, making your data exploration as smooth and effective as Woody Boyd’s charm. No more confusion or missteps.
\nCancelled Queries: Cancelled queries now appropriately show as “cancelled,” clearing up any confusion and ensuring you’re not left wondering what went wrong. It’s straightforward communication, just how Coach would have wanted it.
\nImproved Performance of Loading Query History: We’ve supercharged the performance of loading your query history, making it faster than ever. It’s like getting your data served up by Sam himself—quick, efficient, and with a smile.
\nFix duplicates on child properties with same names: An unfortunate little gremlin meant in certain conditions child properties with the same name as a parent would get incorrect values.
\nSo, here’s to Orbital 0.27.0 — Cheers to faster data, better performance, and a community where everyone is connected! 🍻
(The post 0.27 is Out - Retry, Cache Eviction and UX improvements appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2024-01-27-release-announcement-0-27-0", "title": "0.27 is Out - Retry, Cache Eviction and UX improvements", "summary": "Orbital 0.27.0 - The \"Cheers\" Edition - Release Notes", "image": "https://orbitalhq.com/assets/title-card-i06M7AW0.jpg", "date_modified": "2024-01-27T00:00:00.000Z", "date_published": "2024-01-27T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2024-01-26-cache-eviction", "content_html": "![\"\"/](\"https://orbitalhq.com/assets/cover-image-CjJkw9qI.png\")
Orbital now honours HTTP cache headers on HTTP responses, when a cache is enabled for a query.
\nAs described in Caching Orbital provides ability to cache query results with @Cache annotation:
@Cache(connection = "mycache")find { Film[] }Let assume that you have a rest end point returning list of films:
\nservice FilmServices { @HttpOperation(method = "GET", url = "...") operation listFilms():Film[]}If your Rest operation returns Cache-Control header in its response,\nOrbital will take the max-age directive into account and expire the cached query result accordingly.
Here as an example response with Cache-Control header:
\n![\"\"/](\"https://orbitalhq.com/assets/http-response-cache-control-wDWMvd05.png\")
max-age=144004 will get Orbital to cache the Film list for 4 hours. After 4 hours, the items in the query cache will expire automatically.
Read more about caching in our docs
(The post Cache Eviction support appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2024-01-26-cache-eviction", "title": "Cache Eviction support", "summary": "Orbital's caching layer now supports HTTP Cache headers", "image": "https://orbitalhq.com/assets/cover-image-CjJkw9qI.png", "date_modified": "2024-01-26T00:00:00.000Z", "date_published": "2024-01-26T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2024-01-26-retry-operations", "content_html": "![\"\"/](\"https://orbitalhq.com/assets/cover-image-xte7Vc4K.jpg\")
Let’s say you need to stitch Film data with reviews coming from an unreliable third party Rest Api:
\nservice ReviewsApi { @HttpOperation(method = "GET", url = "https://reviews/{id}") operation getReviews(id: FilmId): FilmReview[]}The third party REST API gives you intermittent HTTP 500s as it can’t cope with user requests at particular times during day.
\nTo address such outages, you can now define a HttpRetry settings in Taxi for the operation.
Orbital Supports two HttpRetry policies:
Let say you want to Orbital to retry ‘getReviews’ operation when it responds with Http 500. You want Orbital to try the operation at most 10 times and wait 5 seconds between each retry.\nHere is how you can modify the taxi definition:
\nservice ReviewsApi { @HttpOperation(method = "GET", url = "https://reviews/{id}") @HttpRetry(responseCode = [500], fixedRetryPolicy = @HttpFixedRetryPolicy(maxRetries = 10, retryDelay = 5)) operation getReviews(id: FilmId): FilmReview[]}You can trigger the retry mechanism for multiple response codes as well, here is how you can modify previous Taxi definition to trigger the Retry mechanism when the remote service returns either Http 500 or Http 502
\nservice ReviewsApi { @HttpOperation(method = "GET", url = "https://reviews/{id}") @HttpRetry(responseCode = [500, 502], fixedRetryPolicy = @HttpFixedRetryPolicy( maxRetries = 10, retryDelay = 5 )) operation getReviews(id: FilmId): FilmReview[]}With exponential delay retry policy, Orbital will wait progressively longer intervals between consecutive retries:
\nservice ReviewsApi { @HttpOperation(method = "GET", url = "https://reviews/{id}") @HttpRetry(responseCode = [500, 502], fixedRetryPolicy = @HttpExponentialRetryPolicy(maxRetries = 10, retryDelay = 5, jitter = 0.5)) operation getReviews(id: FilmId): FilmReview[]}With the above definition, Orbital will try invoking the Rest at most 10 times in case of Http 500 or Http 502 errors.
\nHowever, the delay between retries will increase exponentially.
\nWith a jitter value between 0 and 1, you add some randomness to the delay time by introducing a random delay, or “jitter”, to the next retry delay time.\nThis ensures that the retries are not synchronous and reduces the likelihood of a retry storm.
Here’s how the table would look with exponential backoff with Jitter:
\n| Retry Attempt | Delay Time (seconds) | \tJitter Range (seconds) | Actual Delay Time (seconds) |\n| ------------- | ---- -----------------|------------------------- |-----------------------------|\n| 1 | 1.0 | 0.5 | 1-0 - 1.5 |\n| 2 | 2.0 | 0.5 | 1-5 - 2.5 |\n| 3 | 4.0 | 0.5 | 3.5 – 4.5 |\n| 4 | 8.0 | 0.5 | 7.5 – 8.5 |\n| 5 | 16.0 | 0.5 | 15.5 – 16.5 |
\nHttp retries is out in 0.27. Read more about it over in our docs
(The post Http Retry Support appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2024-01-26-retry-operations", "title": "Http Retry Support", "summary": "If at first you don't succeed", "image": "https://orbitalhq.com/assets/cover-image-xte7Vc4K.jpg", "date_modified": "2024-01-26T00:00:00.000Z", "date_published": "2024-01-26T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2024-01-25-better-query-compilation-errors", "content_html": "![\"\"/](\"https://orbitalhq.com/assets/query-compilation-error-CQhcC4Tl.gif\")
Some UI/UX love for Orbital now, with a fine tuning of how compilation errors are being displayed on screen.
\nWe’ll continue to improve the surfacing of messages like this throughout Orbital, allowing a more streamlined experience for users.
(The post Better query compilation errors appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2024-01-25-better-query-compilation-errors", "title": "Better query compilation errors", "summary": "description goes here", "image": "https://orbitalhq.com/assets/query-compilation-error-CQhcC4Tl.gif", "date_modified": "2024-01-25T00:00:00.000Z", "date_published": "2024-01-25T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2024-01-15-m2-images", "content_html": "![\"\"/](\"https://orbitalhq.com/assets/cover-image-C7euE211.png\")
Some users have been experiencing errors when running our docker images on\nApple Silicon Macbook Pro’s (M1-3 et al).
\nThe issue appears to be related to the base image we use for our Docker images - eclipse-temurin:alpine.
To address this, we’ve started producing extra images, based on Ubuntu Jammy.
\nGrab the images with the -jammy suffix, eg:
0.27.0-jammynext-jammyThese images aren’t suitable for production usage, as the Ubuntu Jammy base image contains\nsignificantly more security CVE’s than the -alpine images.
However, for local developer environments, they’re great - mainly because they don’t crash. Brilliant.
(The post Apple Silicon Friendly docker images available appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2024-01-15-m2-images", "title": "Apple Silicon Friendly docker images available", "summary": "New docker images for M2 Macbooks", "image": "https://orbitalhq.com/assets/cover-image-C7euE211.png", "date_modified": "2024-01-15T00:00:00.000Z", "date_published": "2024-01-15T00:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2024-01-05-http-headers-date-math", "content_html": "The @HttpHeader annotation now is now supported, for setting headers on HTTP requests.
For example:
\nservice MyService { @HttpOperation(method = "GET", url = "...") // A fixed, static header @HttpHeader(name = "Consumes", value = "application/json") operation findPeople():Person[]\n // A header that's calculated operation findPeople( @HttpHeader(name = "If-Modified-Since") ifModifiedSince : Instant = addDays(now(),-7) ):Person[]}You can also pass header values in using the given {} clause in a query:
service MyService { operation findPeople( @HttpHeader(name = "Cache-Control", prefix = "max-age=") cacheMaxAge : CacheMaxAge ):Person[]}\n// which is then invoked as:given { maxAge : CacheMaxAge = 64000 } find { Person[] }Read more about it in our docs
\nThe stdlib in Taxi has been expanded to add date math functions to the stdlib:
\naddMinutesaddDaysaddSecondsnowparseDateRead more about these in the Taxi docs
(The post Http Headers and Date Math appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2024-01-05-http-headers-date-math", "title": "Http Headers and Date Math", "summary": "describption goes here", "image": "https://orbitalhq.com/changelog-cards/2024-01-05-http-headers-date-math.png", "date_modified": "2024-01-05T01:00:00.000Z", "date_published": "2024-01-05T01:00:00.000Z" }, { "id": "https://orbitalhq.com/changelog/2024-01-05-auth-with-cognito-azure", "content_html": "![\"\"/](\"https://orbitalhq.com/assets/changelog-cognito-auth-BtruFZU7.png\")
Orbital now supports authentication and authorization with Azure AD (Entra) and AWS Cognito
\nThis expands our OpenId Connect auth implementation (we already support Keycloak).
\nFull documentation with vendor-specific tutorials is now available in our sections on Authentication and Authorization.
(The post Auth with AWS and Azure appeared first on Orbital Changelog.)
", "url": "https://orbitalhq.com/changelog/2024-01-05-auth-with-cognito-azure", "title": "Auth with AWS and Azure", "summary": "describption goes here", "image": "https://orbitalhq.com/assets/changelog-cognito-auth-BtruFZU7.png", "date_modified": "2024-01-05T00:00:00.000Z", "date_published": "2024-01-05T00:00:00.000Z" } ] }