Repository: geldata/gel
Pull request: Make schema::Type.from_alias include generated target types
Aliases with nested shapes need to create schema types for
those views, and it gives the names like `__UserAlias__deck`.

These are types that have `is_view` as True inside the compiler
but don't have an `expr` field, so this fact isn't exposed
to introspection at all.

An alternative would be to add a new field (`is_view`, perhaps)
instead of changing `from_alias`, but I think that having
`from_alias` be true on the target types generated from alias
definitions makes sense.

Needed to fix edgedb/edgedb-studio#13.

Problem statement:
Aliases with sub shapes break data view
If you point the data viewer at the `User` table from the `cards` schema in the test suite, it runs a broken query, with the relevant part being something like:
```
__default__AwardAlias__winner_name_upper := ([is default::__AwardAlias__winner].name_upper)[<__std__::int64>$__edb_arg_8:<__std__::int64>$__edb_arg_9]
```

I think the problem is that edgedb-studio doesn't realize is a synthesized type made as part of an alias.

And, actually, looking at the schema, I don't know if there really *is* a good way to tell that (other than looking at the underscores and the names mentioned by them).

I'll try to figure out how to expose this in the schema.

Hints from issue discussion:

Commit message: Make schema::Type.from_alias include generated target types

Aliases with nested shapes need to create schema types for
those views, and it gives the names like `__UserAlias__deck`.

These are types that have `is_view` as True inside the compiler
but don't have an `expr` field, so this fact isn't exposed
to introspection at all.

An alternative would be to add a new field (`is_view`, perhaps)
instead of changing `from_alias`, but I think that having
`from_alias` be true on the target types generated from alias
definitions makes sense.

Needed to fix edgedb/edgedb-studio#13.

Patch to review:
diff --git a/edb/buildmeta.py b/edb/buildmeta.py
index 63eb547b21f..c1ec5058c1b 100644
--- a/edb/buildmeta.py
+++ b/edb/buildmeta.py
@@ -44,7 +44,7 @@
 
 
 # Increment this whenever the database layout or stdlib changes.
-EDGEDB_CATALOG_VERSION = 2022_04_05_00_00
+EDGEDB_CATALOG_VERSION = 2022_04_06_00_00
 EDGEDB_MAJOR_VERSION = 2
 
 
diff --git a/edb/lib/schema.edgeql b/edb/lib/schema.edgeql
index ba11ea1771b..d1593b59a43 100644
--- a/edb/lib/schema.edgeql
+++ b/edb/lib/schema.edgeql
@@ -76,7 +76,8 @@ CREATE TYPE schema::PseudoType EXTENDING schema::Type;
 
 ALTER TYPE schema::Type {
     CREATE PROPERTY expr -> std::str;
-    CREATE PROPERTY from_alias := EXISTS(.expr);
+    CREATE PROPERTY expr_type -> int64;
+    CREATE PROPERTY from_alias := EXISTS(.expr_type);
     # Backwards compatibility.
     CREATE PROPERTY is_from_alias := .from_alias;
 };


Code review comments:
diff_hunk: @@ -76,7 +76,8 @@ CREATE TYPE schema::PseudoType EXTENDING schema::Type;
 
 ALTER TYPE schema::Type {
     CREATE PROPERTY expr -> std::str;
-    CREATE PROPERTY from_alias := EXISTS(.expr);
+    CREATE PROPERTY expr_type -> int64;
path: edb/lib/schema.edgeql
text: @user1:
Do we really need to expose `expr_type`?

@author:
That is where `is_view` is computed from in the server code, so it's the main source of truth for this. 

I think it would also work to expose `alias_is_persistent`?

Or we could add a new `Field`

@user2:
What's `expr_type`? Why is it an int?

@author:
It's an enum that indicates what kind of statement (select, insert, update, etc) a type is based on. The actual value is not really important here, but its presence is currently the main source of truth for whether a type is a view or not.

I'm going to rename `alias_is_persistent` to `is_persistent_alias` and expose that instead

@author:
Or maybe just add a `from_alias` field?

@user2:
Can we call it `is_alias`?

@user1:
We don't use `is_` prefixes in schema anymore.