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
It is often the case that join tables have additional information beyond linkage. I'm working through the "correct" way to reason about these in the graph sense. In the graph, the join table is typically an implementation detail for walking an edge, so there is no place to put a query for the quantification without generating an additional "level" of the graph query.
Possibilities are to map the quantification to the target table (as-if it was there). Navigation in both directions should "make sense". Need to explore use-cases and think through the possibilities before implementing this.
Some initial thoughts:
Allow configuration of a join so that only specific values on the join table are allowed (e.g. active = true). This would allow for filtering that the client/server can be ignorant of.
Allow configuration so that join table data columns can be mapped in one direction or the other (or both?). E.g. a quantity on an invoice-items many-to-many join could be mapped as-if the quantity was stored as an attribute on the item.
The text was updated successfully, but these errors were encountered:
It is often the case that join tables have additional information beyond linkage. I'm working through the "correct" way to reason about these in the graph sense. In the graph, the join table is typically an implementation detail for walking an edge, so there is no place to put a query for the quantification without generating an additional "level" of the graph query.
Possibilities are to map the quantification to the target table (as-if it was there). Navigation in both directions should "make sense". Need to explore use-cases and think through the possibilities before implementing this.
Some initial thoughts:
The text was updated successfully, but these errors were encountered: