You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(ogar-adapter-surrealql): emit array<record> for to-many associations (#2 Stage A)
W3.3's "One2many/Many2many array<record>" emitter gap: the shared SurrealQL
emitter rendered only the owning side (BelongsTo → record<X>) and dropped
to-many associations to a comment marker. Now that the lift carries the
association (OGAR #132 `relation_kind` → HasMany/HasAndBelongsToMany + comodel),
`emit_field_assoc` renders both as `array<record<comodel>>`:
- BelongsTo (Many2one) -> record<X> / option<record<X>> (unchanged)
- HasMany (One2many) -> array<record<X>> (NEW)
- HasAndBelongsToMany (Many2many) -> array<record<X>> (NEW)
- HasOne (Rails-only, non-owning) -> comment marker (unchanged)
Target handling mirrors the owning-side record<X> exactly (dotted Odoo comodels
are quoted), so no new normalization. The One2many *computed* `VALUE
<-comodel.<inverse> READONLY` reverse-link is the separate W3.3 "computed VALUE"
gap and is deferred; this lands the structural array TYPE. Parse-back of
`array<record<…>>` is the companion `surrealdb-parser` follow-up — today's
`walk` recovers the owning-side record<X> only (same emit-richer-than-parse
asymmetry the prior comment-marker had; the gated round-trip tests cover
BelongsTo + primitives, unaffected).
This is #2 Stage A from odoo-rs #19 — it unblocks deleting od-ontology's native
emit fork (W3.3) once the shared emitter covers the schema.
Verified via probe (default features, no surrealdb): 22 tests pass (3 new:
has_many/has_and_belongs_to_many → array<record>, has_one → comment),
clippy -D warnings clean. The emit side is pure string-gen (no surrealdb);
the OGAR workspace's surrealdb-parser leg builds on CI.
Co-Authored-By: Claude <noreply@anthropic.com>
0 commit comments