Skip to main content
Use the @bijection/connectors/orientdb entrypoint to declare OrientDB resources.

​
Availability

This page describes the pinned source package. Published availability is unestablished for this artifact. Source build and package availability.

​
Resources and modes

Declare a resource in application code, then bind deployment-specific settings and credentials. See typed resources, connections and source inspection.

​
Documents, vertices and edges of one class

​
rid: Whole class walked by @rid, versioned by @version, point-read deletions and an update conditioned on @version

The following example matches configuration standard.

​
Configuration: standard

Case: orientdb/records/rid/standard. Connection and resource configuration are declared by this exact case. Credential kind: orientdb. Keep credential material in the private credential inventory.
Native admission analysis is available for this exact declaration. Collection: records
Recorded checks Hosted qualification: unestablished for this catalog configuration. Installed connections report their own identity, authority and current status.

​
Configuration: edges

Case: orientdb/records/rid/edges. Connection and resource configuration are declared by this exact case. Credential kind: orientdb. Keep credential material in the private credential inventory.
Native admission analysis is available for this exact declaration. Collection: records
Recorded checks Hosted qualification: unestablished for this catalog configuration. Installed connections report their own identity, authority and current status.

​
Configuration: writes

Case: orientdb/records/rid/writes. Connection and resource configuration are declared by this exact case. Credential kind: orientdb. Keep credential material in the private credential inventory.
Native admission analysis is available for this exact declaration. Collection: records
Commands
Recorded checks Hosted qualification: unestablished for this catalog configuration. Installed connections report their own identity, authority and current status.

​
Provider guidance

Compiled declaration examples and configuration details are published in the connector reference. orientdb.records.rid({ class, schema, fields?, pageRows?, every?, reconcileEvery?, writes? }) reads the records of one class — documents, vertices or edges, with the class’s subclasses — through the OrientDB server’s HTTP REST API (port 2480 by default). Bind the server origin (baseUrl) and the database name (database) on the connection, and an orientdb.credential(name) with a basic envelope: OrientDB authenticates every request with HTTP Basic against the database’s own users. The user needs read on the class, and update on it for writes. A server on premises is reached through a network relay route.
  • Mechanism. Each page is SELECT @rid AS _rid, @version AS _version, @class AS _class, <fields> FROM <class> WHERE @rid > <last> ORDER BY @rid LIMIT n through POST /command/<database>/sql (pageRows, 100, at most 128), OrientDB’s documented RID pagination. No field says when a record changed, so every pass walks the whole class and a shorter page ends it.
  • Identity and version. A record is keyed by its record id #cluster:position and versioned by @version, the MVCC counter every save increments, so an unchanged record is not republished. _class names the record’s own class.
  • Graphs. An edge’s out and in are links, written as RID text; map them with fields ({ from: "out", to: "in" }). Fields are projected by name, so a vertex’s link bags are read only when declared.
  • Deletions. OrientDB has no change feed over HTTP, and Live Query runs over the binary protocol only, so nothing hints a change. A record missing from a walk stays published. The reconciliation sweep (reconcileEvery, daily) reads each published RID with GET /document/<database>/<rid>; a 404, which the server answers exactly when the record does not load, withdraws it. Other answers settle nothing.
  • Writes (opt-in writes: { governingRule, fields }). update sets the named fields with UPDATE <rid> SET ... WHERE @version = ?, the observed version passed as a JSON integer. The answered count decides: 1 applied, 0 refused (the record moved on or is gone); a 409 is a save that lost a race inside the statement. 500 and 423 are unknown, and a lost answer stays unknown: a later version does not say which write produced it. PUT /document with If-Match is not used: the server applies the version only when it is positive and skips the check when nothing changed.
Limits: a record’s absence is only as strong as the point read; whether a 3.1 security policy that hides a record makes its read answer 404 is unconfirmed, so bind a user that reads the whole class. A truncated or recreated class can reuse RIDs, and a new record at an old RID with an equal version is not republished. Updates of edge records are unconfirmed (OrientDB documents UPDATE EDGE for moving their ends). Not established: no OrientDB server has been reached. Taken from the 3.2 REST reference and the 3.2.x server source: the {"result": [...]} answer, the count row an UPDATE answers, RID projections written as #c:p text, 404 for a record that does not load and 409 for a concurrent modification.

​
Provider references

Provider references and prerequisites are maintained in the connector guidance above. No separate provider-documentation review date is recorded.

​
Source and evidence

Canonical connector source, native analysis and check receipts. Connector artifact: 905888ea276a2a28e36981a79e8142b2547ea451c3e63162cb6915ad4a7d1305. The resource declaration examples above are compiled and compared with exact catalog declarations. Recorded checks apply only to their source, declaration and runtime identities. Configure a connection and inspect its status to establish deployment-specific readiness.