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
{{ message }}
This repository has been archived by the owner on May 31, 2024. It is now read-only.
I'm not sure if this is the right terminology, but what I mean is:
// type 1, currently supported
post = {
id: ...,
title: ...,
commentIds: ['123foo', '456bar']
}
comment = {
id: '123foo',
body: ...,
}
// type 2 relation, not yet supported
post = {
id: 'foo123',
title,
}
comment = {
id,
body,
postId: 'foo123'
}
The way it would work is if you define a relation in your regular schema then it's assumed it's a type 1 relation since it relies on a "physical" db field (commentsIds). But if you define it in your apiSchema then it's assumed it's a type 2 relation since there would be no corresponding field to look up ids in.
The text was updated successfully, but these errors were encountered:
hasMany2 - this reminds me of withMulti2 which intuitively vulcan devs might thing hasMany2 is a replacement for hasMany.
hasManyForeign like foreign key?
//Post Schema
relation: {
fieldName: 'comments',
typeName: '[Comment]',
kind: 'hasMany2',
from: `_id` // if from and to are omitted, then this is the structure that is generated
to: `postId`:
}
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'm not sure if this is the right terminology, but what I mean is:
The way it would work is if you define a relation in your regular schema then it's assumed it's a type 1 relation since it relies on a "physical" db field (
commentsIds
). But if you define it in your apiSchema then it's assumed it's a type 2 relation since there would be no corresponding field to look up ids in.The text was updated successfully, but these errors were encountered: