1.0 Beta 1​

This changelog summarizes new features and breaking changes in EdgeDB 1.0 beta 1 “Sirius”.

Migrations​

This Beta release features the fully implemented RFC 1000 for the first time. It is now possible to manage migrations from the CLI, by supplying the new schema file and following interactive prompts.

Let’s say we start with the following schema for a simple chat app:

  1. module default {
  2. type User {
  3. required property name -> str;
  4. required property email -> str;
  5. required property password_hash -> str;
  6. }
  7. type Message {
  8. required link author -> User;
  9. required property body -> str;
  10. required property timestamp -> datetime {
  11. default := datetime_current()
  12. }
  13. }
  14. };

We create a directory app_schema and write the above into a app_schema/schema.esdl file inside it. Then we can initialize our project database by running edgedb create-migration:

  1. edgedb -I chatapp create-migration --schema-dir app_schema
  1. did you create object type 'default::User'? [y,n,l,c,b,s,q,?]
  2. ?
  3. y - confirm the prompt, use the DDL statements
  4. n - reject the prompt
  5. l - list the DDL statements associated with prompt
  6. c - list already confirmed EdgeQL statements
  7. b - revert back to previous save point, perhaps previous question
  8. s - stop and save changes (splits migration into multiple)
  9. q - quit without saving changes
  10. h or ? - print help
  11. did you create object type 'default::User'? [y,n,l,c,b,s,q,?]
  12. y
  13. did you create object type 'default::Message'? [y,n,l,c,b,s,q,?]
  14. y
  15. Created app_schema/migrations/00001.edgeql, id:
  16. m1ufwaxcqiwcq3ttcujnxv6f3jewhfrywc442z6gjk3sm3e5fgyr4q

This creates the first migration file app_schema/migrations/00001.edgeql. After reviewing it to make sure everything is in order, we can apply the migration with the following command:

  1. edgedb -I chatapp migrate --schema-dir app_schema
  1. Applied m1ufwaxcqiwcq3ttcujnxv6f3jewhfrywc442z6gjk3sm3e5fgyr4q
  2. (00001.edgeql)

In the course of implementing our app we decide to add more features, such as a friends list and multiple chat channels, so we alter our schema to be:

  1. module default {
  2. type User {
  3. required property name -> str;
  4. required property email -> str;
  5. required property password_hash -> str;
  6. multi link friends -> User;
  7. }
  8. type Message {
  9. required link author -> User;
  10. required property body -> str;
  11. required property timestamp -> datetime {
  12. default := datetime_current()
  13. }
  14. link channel -> Channel;
  15. }
  16. type Channel {
  17. required property title -> str;
  18. property description -> str;
  19. }
  20. };

And we apply the changes by using edgedb create-migration and edgedb migrate commands again:

  1. edgedb -I chatapp create-migration --schema-dir app_schema
  1. did you create object type 'default::Channel'? [y,n,l,c,b,s,q,?]
  2. y
  3. did you create link 'channel' of object type 'default::Message'?
  4. [y,n,l,c,b,s,q,?]
  5. y
  6. did you create link 'friends' of object type 'default::User'?
  7. [y,n,l,c,b,s,q,?]
  8. y
  9. Created app_schema/migrations/00002.edgeql, id:
  10. m1grkbj7z3fwvj6qe7ib72xdc6urj6ih5aynx3ammlrunh6tfefnaa
  1. edgedb -I chatapp migrate --schema-dir app_schema
  1. Applied m1grkbj7z3fwvj6qe7ib72xdc6urj6ih5aynx3ammlrunh6tfefnaa
  2. (00002.edgeql)

At this point we may want to actually create a default channel “Main” and make the channel link required. So we alter the schema to make the link required and run edgedb create-migration again:

  1. edgedb -I chatapp create-migration --schema-dir app_schema
  1. did you make link 'channel' of object type 'default::Message'
  2. required? [y,n,l,c,b,s,q,?]
  3. y
  4. Please specify an expression to populate existing objects in
  5. order to make link 'channel' required:
  6. fill_expr> select Channel filter .title = 'Main' limit 1
  7. Created app_schema/migrations/00003.edgeql, id:
  8. m1ur35mvstn5wafse2kqwmjy4but3l7nigh4cqktxy6kt2j2wuz65a

However, before applying this migration we also add the line insert default::Channel {title := 'Main'}; at the beginning of the migration block in the app_schema/migrations/00003.edgeql file. Now we can actually apply the changes:

  1. edgedb -I chatapp migrate --schema-dir app_schema
  1. edgedb error: could not read migrations in app_schema/migrations:
  2. could not read migration file app_schema/migrations/00003.edgeql:
  3. migration name should be `
  4. m1jmrmawu4uty53clhbat7nvzjbogexyarh2zue6w6ind2kpfalwva` but
  5. `m1ur35mvstn5wafse2kqwmjy4but3l7nigh4cqktxy6kt2j2wuz65a` is used
  6. instead.
  7. Migration names are computed from the hash of the migration
  8. contents. To proceed you must fix the statement to read as:
  9. CREATE MIGRATION
  10. m1jmrmawu4uty53clhbat7nvzjbogexyarh2zue6w6ind2kpfalwva ONTO ...
  11. if this migration is not applied to any database. Alternatively,
  12. revert the changes to the file.

Uh-oh! The migration failed, but the error message actually explains that we need to adjust the migration hash in order to proceed and even supplies us with the new hash. After adjusting the migration file, we can now apply it:

  1. edgedb -I chatapp migrate --schema-dir app_schema
  1. Applied m1jmrmawu4uty53clhbat7nvzjbogexyarh2zue6w6ind2kpfalwva
  2. (00003.edgeql)

So let’s make a minor tweak by renaming the friends link into circle. After updating our app_schema/schema.esdl file we can apply the changes:

  1. edgedb -I chatapp create-migration --schema-dir app_schema
  1. did you rename link 'friends' of object type 'default::User' to
  2. 'circle'? [y,n,l,c,b,s,q,?]
  3. y
  4. Created app_schema/migrations/00004.edgeql, id:
  5. m1lh5julmw2msveqrchwly4qrbpyiof3hevze35d3x35ydrz3fsv3a
  1. edgedb -I chatapp migrate --schema-dir app_schema
  1. Applied m1lh5julmw2msveqrchwly4qrbpyiof3hevze35d3x35ydrz3fsv3a
  2. (00004.edgeql)

The above example shows some of the interactions with the EdgeDB migration management tools. We will keep improving the inference engine that guides the prompts of edgedb create-migration. However, if the suggestion engine fails to provide a perfect fit, the option of adjusting the migration file is always available.

EdgeQL​

  1. ```
  2. create type Foo;
  3. ```
  4. ```
  5. OK: CREATE TYPE
  6. ```
  7. ```
  8. create function foo() -> bool
  9. using (select random() > 0.5);
  10. ```
  11. ```
  12. OK: CREATE FUNCTION
  13. ```
  • Stop using drop to change field value, introduce reset and set syntax to do that (#2031).
  1. ```
  2. alter type Foo {
  3. alter property a {
  4. reset default;
  5. }
  6. };
  7. ```
  • alter ... set type now requires an explicit conversion expression specified in the using clause, if the new type is not assignment-castable from the old type (#2115).
  1. ```
  2. create type Foo {
  3. create property bar -> int64
  4. };
  5. ```
  6. ```
  7. OK: CREATE TYPE
  8. ```
  9. ```
  10. insert Foo {bar := 3};
  11. ```
  12. ```
  13. {default::Foo {id: efcffce4-6471-11eb-8be5-ff6b1f4c46ee}}
  14. ```
  15. ```
  16. alter type Foo alter property bar {
  17. set type str using (<str>.bar ++ '!')
  18. };
  19. ```
  20. ```
  21. OK: ALTER TYPE
  22. ```
  23. ```
  24. select Foo {bar};
  25. ```
  26. ```
  27. {default::Foo {bar: '3!'}}
  28. ```
  • Add a using clause for set required so that en expression to fill in missing values can be specified (#2130).
  1. ```
  2. create type Foo {
  3. create property bar -> str
  4. };
  5. ```
  6. ```
  7. OK: CREATE TYPE
  8. ```
  9. ```
  10. insert Foo;
  11. ```
  12. ```
  13. {default::Foo {id: efcffce4-6471-11eb-8be5-ff6b1f4c46ee}}
  14. ```
  15. ```
  16. select Foo {bar};
  17. ```
  18. ```
  19. {default::Foo {bar: {}}}
  20. ```
  21. ```
  22. alter type Foo alter property bar {
  23. set required using ('init')
  24. };
  25. ```
  26. ```
  27. OK: ALTER TYPE
  28. ```
  29. ```
  30. select Foo {bar};
  31. ```
  32. ```
  33. {default::Foo {bar: 'init'}}
  34. ```
  • Expose link/property readonly aspect in introspection schema (#2147).

  • Drop is_ prefixes from boolean fields in introspection schema. The old field names are kept for backwards compatibility to be deprecated later (#1793).

  • Add support for computed link properties (#2067).

  • Infer and validate volatility for functions (#1937).

  • Allow trailing commas in functions (#1462).

  • Fix handling of implicit path prefix in the else part of unless conflict so that it properly refers to existing object (#2091).

  • Fix issues with enumerate() when applied to objects (#1815) and results of function calls (#1816).

  • Fix drop property for multi properties (#2059).

  • Make sure computed links and properties don’t appear in dump (#2057).

  • Fix accessing links on objects that come from functions and other sources that aren’t simple paths (#1887).

Command-Line Tools​

  • Add create-migration command.

Bindings​

  • Release edgedb-go driver.

  • Update the edgedb-python driver to v0.13.0.

  • Update the edgedb-js driver to v0.13.0.

  • Implement RFC 1004 features for Python and JavaScript drivers.

    • Add retrying_transaction() method for automatically retrying transactions (retryingTransaction() in JavaScript, RetryingTx() in Go):
  1. ```
  2. for tx in con.retrying_transaction():
  3. with tx:
  4. tx.execute('''
  5. insert Message {
  6. body := 'Hello'
  7. };
  8. ''')
  9. ```
  10. - Add `raw_transaction()` method and deprecate `transaction()` for single-use transactions that will not be automatically retried (`rawTransaction()` in JavaScript, `RawTx()` in Go):
  11. ```
  12. tr = con.raw_transaction()
  13. with tr as with_tr:
  14. with_tr.execute('''
  15. insert Message {
  16. body := 'Hello'
  17. };
  18. ''')
  19. ```
  20. - Add `wait_until_available` (measured in seconds) configuration parameter (`waitUntilAvailable` in JavaScript):
  21. ```
  22. con = edgedb.connect(
  23. user='edgedeb',
  24. wait_until_available=10
  25. )
  26. ```