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
When we have a foreign key in Rel8, we don't really know if it's one-to-one or one-to-many.
In fact we don't really distinguish foreign keys from normal values at all.
It would be nice to encode this information somehow. I don't have a concrete design. But it would really help if I could just tell from a glance that a certain line will always succeed or always give exactly one result.
This is always a source of uncertainty when writing or reading queries.
The text was updated successfully, but these errors were encountered:
This has come up at various points I think, but I'm not entirely convinced. I'm mostly worried that the typing overhead is going to become annoying, or impair inference. I could be wrong though - I've never tried! My general advice is to push this in to naming. I encourage FKs be represented by "join functions", like projectOwner :: Project Expr -> Query (User Expr). Maybe this idea could be extented with a naming convention to indicate cardinality: projectOwner1 or something, vs projectCollaboratorsN. Certainly something to think about here.
I was thinking as well, with foreign keys, you know that the query will always succeed, so we could theoretically have projectOwner :: Project Expr -> User Expr. I'm not sure if this makes any sense at all wrt to the implementation, but this would be a nice way to express that there is always exactly one User.
When we have a foreign key in Rel8, we don't really know if it's one-to-one or one-to-many.
In fact we don't really distinguish foreign keys from normal values at all.
It would be nice to encode this information somehow. I don't have a concrete design. But it would really help if I could just tell from a glance that a certain line will always succeed or always give exactly one result.
This is always a source of uncertainty when writing or reading queries.
The text was updated successfully, but these errors were encountered: