Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QueryBuilder does not translate type converted properties correctly #21

Open
quinchs opened this issue Nov 28, 2022 · 0 comments
Open
Labels
bug Something isn't working query builder

Comments

@quinchs
Copy link
Collaborator

quinchs commented Nov 28, 2022

Summary

With the introduction of type converters, the bridge between Expressions and EdgeQL starts to bend. Currently, the querybuilder correctly translates assignment/initializations expressions and shapes, but it falls short at expressions that are directly influenced by type converted properties.

Example:

public class User
{
    [EdgeDBTypeConverter(typeof(UlongToStringConverter))]
    public ulong SnowflakeId { get; set; }
}

...

ulong targetId = 12345;

var result = await QueryBuilder
    .Select<User>()
    .Filter(x => x.SnowflakeId  == targetId)
    .ExecuteAsync();

The expression x => x.SnowflakeId == targetId does not take into account that SnowflakeId is actually a string in EdgeDB, and treats targetId as a number, producing the following snippet:

.snowflake_id = <int64>$random_var_name

which errors due to the type difference of str and int64.

Potential solution

We can look to quantum mechanics for a solution, taking inspiration from the principle of entanglement. The query builder can find all expressions entangled with a particular type converted property and put the entangled references thru the same type converter to build the EdgeQL query.

With this approach, our above expression follows this logic:

  1. Binary expression is translated
  2. The member expression x.SnowflakeId is discovered as a type converted property.
  3. The expression tree is walked backwards from the MemberExpression and any values with the same shared type as the member expression are updated with the converted value.

I believe that a ExpressionVisitor can be used to achieve this, if not we can simply just rebuild the effected expressions.

@quinchs quinchs added bug Something isn't working query builder labels Nov 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working query builder
Projects
None yet
Development

No branches or pull requests

1 participant