SolarflareDB
Demo guide / Query reference

Query the model you built.

Filter root records, follow declared routes, constrain the participants, and inspect the evidence for every matched root.

This JSON format is executed by the local demo engine. It is not a SolarflareDB production API, SQL dialect, or SDK contract.

Start with records

Find active accounts
{
  "type": "Account",
  "where": [{ "field": "status", "op": "eq", "value": "active" }],
  "limit": 50
}

Root where conditions are combined with AND. You can filter on declared fields or the metadata properties id and type. The value must match the declared field type; the engine does not silently convert a numeric string into a number.

OperatorMeaning
eq, neStrict equality or inequality. Explicit null values may be compared. A missing property is distinct from null.
containsCase-insensitive substring match on a string field.
gt, gte, lt, lteOrdered comparisons on strings or numbers. Null or missing fields do not match.
inMembership in an array of up to 100 correctly typed values.

Unknown properties at any query level are rejected. A misspelled filter must not silently turn a constrained query into an unrestricted result.

Each related clause starts from the same root. A root qualifies when every clause has at least one matching target. Separate clauses are independent existential conditions, not implicit joins between their paths.

A step names a relation, an optional target role, and a direction of out or in. The default is out. Use the target role to disambiguate relationships with several participants.

Constrain the same relationship

An account with an Enterprise subscription to Identity and a Team subscription to Checkout should not qualify as having an affected Enterprise Checkout subscription. Place the plan constraint on the same subscription step that reaches the product.

Corrected enterprise-exposure query
{
  "type": "Account",
  "where": [
    {
      "field": "status",
      "op": "eq",
      "value": "active"
    }
  ],
  "related": [
    {
      "label": "Plan",
      "type": "Plan",
      "steps": [
        {
          "relation": "subscription",
          "role": "plan"
        }
      ],
      "where": [
        {
          "field": "tier",
          "op": "eq",
          "value": "Enterprise"
        }
      ]
    },
    {
      "label": "Degraded service",
      "type": "Service",
      "steps": [
        {
          "relation": "subscription",
          "role": "product",
          "participants": {
            "plan": [
              {
                "field": "tier",
                "op": "eq",
                "value": "Enterprise"
              }
            ]
          }
        },
        {
          "relation": "runs_on",
          "role": "service"
        },
        {
          "relation": "depends_on",
          "role": "dependency",
          "repeat": {
            "min": 0,
            "max": 3
          }
        }
      ],
      "where": [
        {
          "field": "status",
          "op": "eq",
          "value": "degraded"
        }
      ]
    }
  ],
  "limit": 50
}

participants.plan is evaluated against the plan record of each candidate subscription. The matching plan and traversed product therefore belong to that same relationship. The separate Plan clause supplies a visible plan match; the participant constraint is what preserves the product-plan association on the service path.

Run this query

Bound the traversal

A repeat step follows a relation between its inclusive min and max bounds. A zero-hop option includes the current record, which is why the exposure query can find both a directly degraded service and a degraded dependency.

The engine uses simple paths: a record already visited on the current path is not revisited. Cycles do not create endless traversal. The limits are five related clauses, six steps per clause, a maximum repeat depth of four, ten field conditions per filter set, and 30,000 counted traversal expansions. A work-limit error is an error, not a partial result presented as complete.

Understand the result

Each result row contains the root record, matching related records and paths, and evidence references. Every participant of a traversed relationship is included in the evidence, even when that participant was used as a constraint rather than the path destination.

The result reports the number of matched roots and whether the selected output limit truncated them. “All query matches” means the full answer to the bounded query in the selected view and revision. It does not mean the traversal discovered every reachable record in an unbounded graph.

The builder edits the first root condition and preserves additional conditions entered in JSON. Edit the complete JSON to manage multiple root filters or participant constraints.

← Data modelHistory and sources →