You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To remove the need of a reference to surrealdb.net in the domain model an id of string type should be handled as well as the Thing type. Maybe mapping id to any properties that has the [Key] attribute. This would make it easier to adopt existing EF models.
The text was updated successfully, but these errors were encountered:
The original intention was to be agnostic to any data-oriented solution like EF and to follow the behavior of the existing client SDKs for SurrealDB. Note that the [Table] + [Key] combo will be supported alongside #10 and the upcoming Query Builder.
The main difference is that [Key] should be unique per table (to point to the record id), per SurrealDB internal behavior.
YesIssues arise when you use old models in postgres or sql server that has a different way of using keys. In that case you might have a UserId column that sholud be mapped to id.I know this is an edge case and a full migration should be a good alternative. It might lessen the work on existing applications to move to Surreal.But Surreal has its way to look at things and it may just not work.Just pushing out some ideas.Sent from my Galaxy
To remove the need of a reference to surrealdb.net in the domain model an id of string type should be handled as well as the Thing type. Maybe mapping id to any properties that has the [Key] attribute. This would make it easier to adopt existing EF models.
The text was updated successfully, but these errors were encountered: