Skip to content

all: remove views - #15

Merged
lesomnus merged 1 commit into
masterfrom
remove-views
Oct 18, 2026
Merged

lesomnus merged 1 commit into
masterfrom
remove-views

Conversation

@lesomnus

Copy link
Copy Markdown
Member

Closes #3.

A view could be declared like an entity and was generated as a read-only one, but nothing ever created it in the database. Wiring it up was not possible either:

  • migrate.Tables held no view. Only the ent schema command reached Graph.Views, and it printed the DDL instead of applying it.
  • Ent inspects tables only, so a view in the desired state would show up as missing on every run.
  • The bundled Atlas (v1.3.0) has a schema.View type, but none of its open-source drivers inspect views or plan adding, changing or dropping them. So the diff half could not be wired, whatever this repository did.

What remained was the entsql.View definition. Only ent schema ever read it, and it had already drifted (wrong table name, wrong column count) without anything noticing. Nothing in this stack declares a view: I searched every cached version of protoc-gen-orm-ent, -go, -service, protobuf-orm and protobuf-merge.

Removed

  • ent.View, ent.Viewer, and load.Schema.View.
  • In gen:
    • Type.IsView, Graph.Views and Graph.MutableNodes. Every node is mutable now, so templates range over Nodes.
    • the notView conditions on the create, update, delete and mutation templates.
  • The IsView branches in the client, ent, entql and privacy templates.
  • entsql.View, entsql.ViewFor and Annotation.ViewAs/ViewFor. The annotation's err field and Err() also go, because only ViewFor ever set the error.
  • schema.NewView, Table.View, the view half of Atlas.realm, and the CREATE VIEW that schema.DDL appended.
  • CleanUser in entc/integration/multischema, and doc/md/schema-view.mdx.

sql.CreateView stays. It belongs to the general SQL builder, not to what ent generates.

UPSTREAM.md lists views under Removed, with what to do when an upstream change adds an IsView branch or ranges over MutableNodes.

A test expectation that was wrong

TestDDL expected owner_id twice in pets. The view next to it caused that: append(pets.Columns[:2], pets.Columns[3]) overwrote fur_color through the shared slice. Without the view, pets has the columns it declares, and the expectations now include fur_color.

Tests

All of the following pass locally:

  • go vet and go test in the root, examples, and dialect/sql/schema/integration.
  • The whole entc/integration matrix with -race -count=2 on SQLite, MySQL 8.0 and 8.4, MariaDB 10.11 and 11.4, and PostgreSQL 14 and 17.
  • The generate gate, which is clean.
  • .github/lint.sh.

🤖 Generated with Claude Code

A view was declared like an entity and generated like a read-only one,
and nothing put it in the database (#3). migrate.Tables held no view:
only the `ent schema` command reached Graph.Views, and it printed the
DDL rather than applying it. Ent inspects tables only, so a view in the
desired state would have read as missing on every run. And the bundled
Atlas plans no view changes at all: v1.3.0 has a schema.View type, but
no driver inspects one or plans adding, changing or dropping one, so
the diff half could not be wired whatever this repository did.

What was left was a definition, entsql.View, that only `ent schema` ever
read and that had already drifted -- a wrong table name and a wrong
column count -- with nothing to say so. Nothing in this stack declares
a view; protoc-gen-orm-ent and the generators beside it never have.

So views go, as Gremlin did:

- ent.View and ent.Viewer; load.Schema.View.
- gen: Type.IsView, Graph.Views, Graph.MutableNodes (every node is
  mutable now, so templates range Nodes), and the notView conditions
  that kept create/update/delete/mutation from a view.
- The IsView branches in the client, ent, entql and privacy templates.
- entsql.View, entsql.ViewFor, Annotation.ViewAs/ViewFor, and the
  annotation's err, which only ViewFor set.
- schema.NewView, Table.View, the view half of Atlas.realm, and the
  CREATE VIEW schema.DDL appended.
- CleanUser in entc/integration/multischema, and doc/md/schema-view.mdx.

sql.CreateView stays: it is the SQL builder's, and says nothing about
what ent generates.

TestDDL's pets table had expected owner_id twice. That was the view
beside it: `append(pets.Columns[:2], pets.Columns[3])` wrote over the
fur_color column through the shared slice. Without the view, pets has
the columns it declares, and the expectations say fur_color.

UPSTREAM.md lists views under Removed, with what to do with an upstream
change that adds an IsView branch.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@lesomnus
lesomnus merged commit 9918a1e into master Oct 18, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

A view is declared and generated, but nothing creates it

1 participant