CodesInChaos
CodesInChaos
Migration from `multi property something: std::str;` to `property something: array<std::str>;` fails
You can use the following migration: ``` ALTER TYPE default::Test { CREATE PROPERTY something2: array; }; UPDATE Test SET { something2 := array_agg(.something) }; ALTER TYPE default::Test { DROP PROPERTY...
In my opinion truncating (towards minus infinity) makes more sense for timestamps than rounding to the nearest value, since truncation will not affect computing properties like the date or the...
One case I frequently run into is mapping non-exhausitive enums from an external system (e.g. a JSON or C API) which represents enums as string or integer. I'd like to...
I'd at least use a macro for tuples. For integers I'd first wait to see if edgedb adds native support for additional integer sizes (with `u8` causing complications because it...
I suggest exposing those internal fields differently: #347
The query functions taking a single arbitrary `Value` looks weird as well, since it's always a list of key-value pairs. I'd have expected some kind of map or named tuple...
If it's a tuple, how does the query access it? Something like `$0` instead of `$name`? My preference would be using a smaller enum `QueryArgs` with only two options (tuple,...
I'd prefer something more trait based, so it works with static typing and not just `Value`. Something along the lines of: 1. Introduce types encapsulating various `Value` variants, like `NamedTuple`...
> Ensure that nothing is re-exported from edgedb-protocol, so that we can make breaking changes in latter without disturbing users I don't see how that's going to work. You can...
One problem with abstracting over `Value` and `Queryable` is context dependent (de-)serialization. `Value` is context dependent (especially on the deserialization side). So far `Queryable` is not. Though there are some...