Reusing a subgraph of ORM in an another ORM instance

[IlyaSemenov]

Following #695, I'd like to discuss whether this real-world scenario can be supported, or at least made less fragile.

In a SaaS web app, I have two ORMs:

• per-tenant: user, form, field, submission, answer
• global: tenant, form, field (no answers)

The use case is, SaaS admin setups forms (more like "form templates"). Tenants choose a form template from the global form catalog and create a local form as a clone of the global form. Tenants then collect form submissions.

The business logic behind forms is fairly complex (1000+ LOC). Fields have multiple types, including heavy composite types like "RICE score", so I'd like to reuse that logic when working with tenant and global forms.

Currently, I use the tenant ORM as the "canonical" source of table definitions, then derive the global ORM from it:

export class FormTable extends TenantFormTable {
  override schema = SAAS_SCHEMA
}

export class FormFieldTable extends TenantFormFieldTable {
  override schema = SAAS_SCHEMA

  // SaaS forms don't have answers; answers are tenant-only.
  // @ts-expect-error I didn't manage to find out how to prevent TS errors on this override.
  override relations = omit(
    (TenantFormFieldTable.instance() as TenantFormFieldTable).relations,
    ["answers"],
  )
}

Business-layer functions that work with forms, such as createForm, retrieve the ORM instance through a service locator. At runtime, they call const db = useDb() rather than relying on a module-level constant. In the SaaS context, I replace/mock the service locator so that it returns the SaaS ORM instance.

This is fragile and not type-safe. The shared form logic is supposed to use only the tables and relations that exist in both ORMs, but there is currently no way to enforce that.

The question is: are there ways to improve DX and make this case somehow better (even if not fully and truly supported)?

[IlyaSemenov]

I just thought, perhaps I could extract some kind of "forms-only ORM" having only form and field, derive from it twice, and use the service like useFormsDb() to work with forms. 🤔 The service provider layer will need to know about all such sub-ORMs, but that's probably fine.

---

UPD: I tried this, but it's also not very straightforward. One of the obstacles is that we need some kind of multiple inheritance then: concrete table classes such as tenant and saas FormTable should somehow derive from both the respective layer's BaseTable (to inherit schema) and the abstract FormTable (to inherit fields). I misinterpreted the issue; this has been already needed with override schema = SAAS_SCHEMA, so nothing new (it's just that it's not only in saas but in both derived ORMs). I will give this approach one more try.

[romeerez]

I'm not sure what can I add to the ORM for this.

  override relations = omit(
    (TenantFormFieldTable.instance() as TenantFormFieldTable).relations,
    ["answers"],
  )

Perhaps, some kind of utility for this?

Maybe just to expose a typed instance to avoid doing this as. instance() is minimally typed for internal needs and that's why it doesn't include the relations.

I looked around a bit, doesn't seem like other ORMs streamline this kind of extending existing tables to omit or add new relations on top. And perhaps this would be easier to support with new classless design, but it's not in a sight yet.