Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strict versioning and relationships #929

Open
dselman opened this issue Oct 22, 2024 · 1 comment
Open

Strict versioning and relationships #929

dselman opened this issue Oct 22, 2024 · 1 comment

Comments

@dselman
Copy link
Contributor

dselman commented Oct 22, 2024

Discussion 🗣

Given these namespaces:

namespace person@1.0.0

concept Person identified by name {
   o String name
}

And:

namespace car@1.0.0
import person@1.0.0.Person

concept Car {
   --> Person owner
}

Any change to the person namespace should cause a change to the car namespace, even though the Car concept only contains a relationship to Person (the fully-qualified type name plus an identifier).

Context

Intuitively it feels like we are being too strict in this case. We know that the Car has a relationship to a Person but the relationship encodes the version number of the Person as well as the identifier.

Contrast with something like this:

namespace car@1.0.0

scalar Relationship extends String regex="resource://person@1.0.0#.*"

concept Car {
   o Relationship owner
}

At runtime we have the same enforcement of relationship, but there is no version dependency between the models, and we cannot statically determine that the Car concept references the Person concept.

Detailed Description

It is not clear what the best answer is here... Perhaps supporting both (as we do now) is the right thing?

Copy link
Contributor

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days.

@github-actions github-actions bot added the Stale label Dec 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant