docs(schema): correct from+to relationship cardinality to many-to-one - #602
Conversation
The @relationship(from:, to:) example joined two scalar attributes (productSku -> sku) but was labeled "useful for many-to-many relationships" — cardinality in Harper is decided by whether the target `to` attribute is an array (search.ts's isManyToMany check), so a scalar-to-scalar join is many-to-one, not many-to-many. The other bug in issue #582 (querying.md resellers example pointing `from` at the singular resellerId) was already fixed on main by 7e373fa before this dispatch ran. Refs #582 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the documentation in reference/database/schema.md to clarify the cardinality rules for foreign key to foreign key relationships using @relationship(from: attribute, to: attribute). The review feedback correctly identifies an inaccuracy in the explanation of how cardinality is determined and provides a clearer, simplified phrasing to resolve the issue.
🚀 Preview DeploymentYour preview deployment is ready! 🔗 Preview URL: https://preview.harper-documentation.harperfabric.com/pr-602 This preview will update automatically when you push new commits. |
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
🚀 Preview DeploymentYour preview deployment is ready! 🔗 Preview URL: https://preview.harper-documentation.harperfabric.com/pr-602 This preview will update automatically when you push new commits. |
Table.ts wires the @relationship resolver for any attribute with `to` set (from+to or to-only) only when the field itself has an array type (attribute.elements?.definition); the scalar `product: Product` field never registers a resolver and 500s on select. Match the field type to what Harper actually requires, and drop the many-to-one cardinality claim in favor of describing the actual resolve behavior. Refs #582 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
🚀 Preview DeploymentYour preview deployment is ready! 🔗 Preview URL: https://preview.harper-documentation.harperfabric.com/pr-602 This preview will update automatically when you push new commits. |
Ethan-Arrowood
left a comment
Ethan-Arrowood
left a comment
There was a problem hiding this comment.
Verified against the resolver in Table.ts on main — the corrected array-typed to example matches actual behavior. One nit: title still says "many-to-one".
sent with Claude Fable 5
🧹 Preview CleanupThe preview deployment for this PR has been removed. |
3 participants
What
Fixes the second bug from #582: the
@relationship(from: attribute, to: attribute)example inreference/database/schema.mdjoins two scalar fields (productSku->sku) but was described as "useful for many-to-many relationships." Reworded the section to state that cardinality follows thetoattribute (scalar -> many-to-one, array -> many-to-many via the array pattern already shown in thefrom-only section above), and relabeled the example's inline comment as many-to-one.Why
Per #582: Harper's
search.tsdecides many-to-many purely by whether the targettoattribute is an array (isManyToMany = Boolean(findAttribute(relatedTable.attributes, attribute.relationship.to)?.elements)). A scalar-to-scalarfrom+tojoin can never be many-to-many, so the old text mislabeled the example and could mislead readers (and downstream agent-rules generation inHarperFast/skills) into modeling it wrong.The issue's first finding (
reference/rest/querying.mdpointingfromat singularresellerIdinstead ofresellerIds) was already fixed onmainby 7e373fa prior to this dispatch — no change needed here.Test plan
npx prettier --check reference/database/schema.md reference/rest/querying.md— passes~/dev/harper'ssearch.tsisManyToManylogic per the issue's citationRefs #582
🤖 Generated with Claude Code