itsezc / lucid Goto Github PK

Preliminary checklist

• I understand that all communication must be in English
• I read the Documentation
• I read the Contributing guide
• I agree to follow the Code of Conduct
• I searched the issues and discussions but couldn't find anything (or linked relevant results below)

Problem

Its a bit verbose to pass type definitions to the @Field() decorator of the target Model, an example of this is:

@Table({ edge: true })
export class SubsidaryOf extends Model {
    @Field({ name: 'in' })
    inside!: Organization

    @Field<SubsidaryOf>({
        assert: ({ inside }, $value) => $value !== inside,
    })
    out!: Organization
}

The @Field() for out should automatically infer the type of SubsidaryOf instead of Organization

Solution

This is currently blocked by microsoft/TypeScript#37300

Resources:
https://stackoverflow.com/questions/71218773/how-typescript-method-decorator-factory-get-target-class-type

Alternatives

No response

Contribution

Yes, I will work on a PR

Keywords

types, infer, field, decorator

Currently SET is not fully supported for Model.update() as values that are integers / numbers and arrays can be incremented and decremented (https://surrealdb.com/docs/surrealql/statements/update) the API should reflect this by adding the aforementioned functionality.

Preliminary checklist

• I understand that all communication must be in English
• I read the Documentation
• I read the Contributing guide
• I agree to follow the Code of Conduct
• I searched the issues and discussions but couldn't find anything (or linked relevant results below)

Problem

The Surreal DB client is not tested, and therefore may fail in production both the WS and REST implementations should ship with unit tests.

Solution

Implement tests with Bun on the client package.

Alternatives

No response

Contribution

Yes, I will work on a PR

Keywords

tests, client, surreal, db

Currently field name overrides with @Field({ name: '<overrides_name>' }) has no impact on the generated query.

Preliminary checklist

• I understand that all communication must be in English
• I read the Documentation
• I read the Contributing guide
• I agree to follow the Code of Conduct
• I searched the issues and discussions but couldn't find anything (or linked relevant results below)

Problem

It would be very intuitive where a Model can reference relations, here is an example use case:

@Table({ name: 'follows', edge: true })
export class Followers extends Model 
{
    @Field({ name: 'in' })
    inside!: User;
    out!: User;
}

@Table({ name: 'follows', edge: true })
export class Following extends Model 
{
    @Field({ name: 'in' })
    inside!: User;

    out!: User;
}

@Table<User>({
    name: 'user',
    permissions: ({ username }) => [
        [['CREATE', 'UPDATE', 'SELECT'], true],
        ['DELETE', AdminScope]
    ],
    auditable: true,
})
export class User extends Model
{
    @Field({ index: 'unique' })
    username: string;

    @Field({ assert: 'email', name: 'email_address', index: 'unique' })
    email?: string;

    bestFriend?: User;

    followers?: Followers[];

    following?: Following[];
}

being able to select, relational fields via the select method
eg. User.select(['username', 'followers', 'following']).build()
SELECT username, <-follows<-user as followers, ->follows->user as following FROM user
also to be able to fetch relational fields via the fetch method
eg. User.select(['username', 'followers', 'following']).fetch(['followers', 'following']).build();

there are several issues which need to be addressed

1. the schema generator must know how to handle the relational fields (i.e do not mistake them for record fields)
2. the select builder must also know how to differentiate between relational and record fields

one solution could be to create a new decorator called @relational
this decorator would be used to decorate the relational fields
@relational(Followers) (could also potentially add more props to this decorator)
the schema generator would then know to ignore these fields
the select builder would also know to ignore these fields

another solution could be to add a new property to the @field decorator
eg. @field({ relation: Followers })

a third solution could be to expand the current select method to accept an instance of a select builder
eg. User.select(['username')]).select(Followers.select())
or expand the in, out logic to handle the relational query

However, further investigation is needed on how one might reference deeply nested relations and an alternative API maybe necessary than the one currently suggested.

Solution

Relation references could be tagged with a decorator i.e. @FieldRelation()

and therefore be usable in Models:

export class Account extends Model
{
     @FieldRelation({ direction: 'in' })
     friends: Friend[]
}

Alternatives

No response

Contribution

No, I cannot contribute further

Keywords

relations, model, query, API

Currently it isn't possible to have:

Account.select()
   .where({
      location: {
         inside: {
            type: 'Point',
            coordinates: [21, 21]
         },
         outside: {
            type: 'Point',
            coordinates: [22, 22]
         }
      }
})
.build()

Account.select()
   .where({
      username: {
         endsWith: 'ends',
         startsWith: 'starts'
      }
   })
.build()

As only one comparison generates a valid query.

Based on surrealdb/surrealdb#1322

Preliminary checklist

• I understand that all communication must be in English
• I read the Documentation
• I read the Contributing guide
• I agree to follow the Code of Conduct
• I searched the issues and discussions but couldn't find anything (or linked relevant results below)

Problem

Currently, the return types are linked to the Model of which they are called by i.e. Account.select() would return Account[], however in some cases the developer may only select a few fields i.e. username and password and therefore returning the full type may be obsolete and provide types which are otherwise invalid.

Additionally, some field types may be sub queries, these should also be handled adequately.

Solution

The builder needs to be aware of such functionality and ensure that only the selected field types are returned.

Alternatives

No response

Contribution

Yes, I will work on a PR

Keywords

dynamic, queries, return, types

Currently, primitive arrays i.e. string[] or number[] is not parsed by the schema generator, further investigation should be undertaken to see if GeoPoint[] and other similar types can be generated.

currently when you do a select query such as
Account.select(['email', 'id']).where({ email: '[email protected]' }).build(); it does not infer the table name, i think it should do so in such a case, and if a user decides to override they can add the from query

not sure if this would be a case of just adding
query = query.concat(' ', 'FROM ', this.query_table || this.query_from); in the select builder, but yeah just wanted to raise it.