Quartz 4

EdgeDB path factoring and allow_bare_dml, apply_access_policies

4 min read

edgedb> select (Sheet.serial, random());
error: QueryError: can not take cross product of volatile operation
  ┌─ query:1:23
  │
1 │ select (Sheet.serial, random());
  │
  • To call once: call random in width
  • To call once per, iclude in shape

Document path factoring behavior

In EdgeQL, common paths are “factored” to the closest surrounding subquery.

This is what allows

select User.first_name ++ ' ' ++ User.last_name

to return one row per user, as well as causing

select (User.name, count(User))

to always report 1 as the count, as well as letting

select (User.name, count(User.friends))

return each user’s number of friends.

I don’t believe that this is currently documented anywhere but https://www.edgedb.com/docs/reference/edgeql/eval, which does not explain it at all, it just shows how to define it.

  • Can’t have a shorter common path prefix than your main expression
    • Can be mindblowing, difficult to reason about
  • Tries to match user expectation
    • When you concatenate first and last name, do you expect cross products for the entire set of users or just per-user
    • If you write a symbol more than once (like User), we assume you mean the same thing
      • can use with to create a different symbol
      • detached
  • to get cross-product, use different symbols
    • If cross-product was default, how would you express that you want the same thing?
  • If not this path factoring, for loop would be required for the simplest case
  • Works great for +, ++
    • Tuple with
  • select count(User.friends)- Counts people who are somebody’s friends
    • if select (count(User.friends), count(User.friends)) gives you 1,1 because the paths are factored out, that’s a problem
    • element-wise functions vs. set-wise functions
      • set-wise take sets- for these, you don’t want cross-products of sets when you combine them
      • element-wise
      • these are defined per parameter, not per function
      • element-wise parameters are refactored
      • set-wise parameters are not refactored unless they have an element-wise companion forcing a refactor
        • Two select statements side-by-side will not be path refactored
    • Re-use the common chunk in the path
      • Stops at aggregates
        • Don’t share common path prefix
    • Talk about scopes
      • After addressing simple side-by-side, go into nesting and scopes
      • Don’t share a common path two selects at the same level, but nested scopes can share common path
      • sub-queries and shapes are nested scopes
      • anything on the same level (parallel defs in with block or parallel arguments) are sibling scopes
      • clauses are usually nested
        • select
          • filter, order by is nested
            • filter- making a decision on each individual element
            • order by- need to refer to something individual to the user
            • meaning is dependent on what you’re selecting
          • limit is parallel
            • limit- global limit, not individual to each individual object
            • should make sense independently of your selection

Approach

  • start with path
  • go into scopes and just start
  • Add to EdgeQL > Paths
    • or another section under EdgeQL after Paths
    • End of EdgeQL section?
      • At the bottom before Transactions (because you don’t need transactions to understand it)
    • Leave reference alone

Undocumented config options

The config options allow_bare_ddl and apply_access_policies appear to not be documented anywhere. They probably should be documented in stdlib/cfg (and maybe reference/configuration?).

These have annotations in the code that may get me to where I need to be.

These are not recommended for users to use directly. Useful for creating tools for EdgeDB.

allow_bare_ddl

Whether DDL is allowed to be executed outside a migration. Once you do the first migration, this gets turns off. Not a good idea to mix migration workflow with bare DDL. On by default when you create project. Turned off when you create a migration.

apply_access_policies

Whether access policies will be applied when running queries. Effectively puts you in super-user mode. Exposed as a checkbox in WebUI (he thinks).

Context: needed for webUI. If you don’t disable, there is stuff that may not be visible to you. Will disable role-based access when that is added.

Document at

Graph View