feat: support for rel and namespace deprecation

[kartikaysaxena]

This PR adds support for relation and namespace level deprecation in schemas.

• Relations and namespaces can now be annotated with a @deprecated(...) directive to indicate they are deprecated.
• When a relationship is written to a deprecated relation or deprecated namespace:
  • A warning or error is generated, depending on the specified deprecation level.
  • In the current implementation, writes fail when an error deprecation is configured.
• Deprecation is associated with the definition/relation decorated with the deprecation.
• A flag is to be passed to enable this feature, namely --enable-experimental-deprecation along with use directive.

Example:

use deprecation

@deprecated(warn, "comments")
definition user {}

definition resource {
  relation viewer: user | @deprecated(warn, "documents can no longer be public") user:*

  @deprecated(error, "comment goes here")
  relation admin: user
}

[!NOTE] Each relation has a object Deprecation assigned to them containing an enum DeprecationType and optional comments, if unspecified DeprecationType defaults to DEPRECATED_TYPE_UNSPECIFIED

[!NOTE] Attempted write with a DELETE operation to a deprecated relation/namespace doesn't fail

(related #2465)

[codecov[bot]]

Codecov Report

:x: Patch coverage is 86.18090% with 55 lines in your changes missing coverage. Please review. :white_check_mark: Project coverage is 79.47%. Comparing base (d4ff660) to head (d98c374).

Files with missing lines	Patch %	Lines
pkg/schema/typesystem.go	74.60%	19 Missing and 12 partials :warning:
pkg/schemadsl/compiler/translator.go	78.79%	8 Missing and 6 partials :warning:
pkg/schemadsl/parser/parser.go	75.00%	6 Missing and 3 partials :warning:
pkg/schemadsl/generator/generator.go	97.37%	1 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2504      +/-   ##
==========================================
+ Coverage   79.46%   79.47%   +0.02%     
==========================================
  Files         456      456              
  Lines       47322    47664     +342     
==========================================
+ Hits        37600    37877     +277     
- Misses       6963     7004      +41     
- Partials     2759     2783      +24     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ecordell]

Just thinking about the UX a bit (we don't have to solve it in this PR - just thinking ahead!) it would be nice to be able to do something like:

definition document {
  relation viewer: user

  @deprecated(warn, "documents can no longer be public")
  relation viewer: user:*
}

which would normally fail validation as a duplicated relation name

[josephschorr]

Just thinking about the UX a bit (we don't have to solve it in this PR - just thinking ahead!) it would be nice to be able to do something like:

definition document {
  relation viewer: user

  @deprecated(warn, "documents can no longer be public")
  relation viewer: user:*
}

which would normally fail validation as a duplicated relation name

Not sure... I kind of prefer:

relation viewer: user | @deprecated(warn, "documents can no longer be public") user:*

[kartikaysaxena]

Just thinking about the UX a bit (we don't have to solve it in this PR - just thinking ahead!) it would be nice to be able to do something like:

definition document {
  relation viewer: user

  @deprecated(warn, "documents can no longer be public")
  relation viewer: user:*
}

which would normally fail validation as a duplicated relation name

Not sure... I kind of prefer:

relation viewer: user | @deprecated(warn, "documents can no longer be public") user:*

this would require extending the support to the type reference, would look into that, or address do that in a follow up

[josephschorr]

Just thinking about the UX a bit (we don't have to solve it in this PR - just thinking ahead!) it would be nice to be able to do something like:

definition document {
  relation viewer: user

  @deprecated(warn, "documents can no longer be public")
  relation viewer: user:*
}

which would normally fail validation as a duplicated relation name

Not sure... I kind of prefer:

relation viewer: user | @deprecated(warn, "documents can no longer be public") user:*

this would require extending the support to the type reference, would look into that, or address do that in a follow up

Followup is fine

[kartikaysaxena]

Just thinking about the UX a bit (we don't have to solve it in this PR - just thinking ahead!) it would be nice to be able to do something like:

definition document {
  relation viewer: user

  @deprecated(warn, "documents can no longer be public")
  relation viewer: user:*
}

which would normally fail validation as a duplicated relation name

Not sure... I kind of prefer:

relation viewer: user | @deprecated(warn, "documents can no longer be public") user:*

this would require extending the support to the type reference, would look into that, or address do that in a follow up

Followup is fine

I added it just a while ago 😅, have added tests too, if anything looks sideways, would revert back to previous commit, or if any other suggestion is taken into consideration regarding the type ref approach for relation deprecation, let me know.

[kartikaysaxena]

Rebased and updated

[kartikaysaxena]

checking on this

[josephschorr]

@kartikaysaxena Sorry, I thought this merged. Can you rebase and resolve conflicts?

[josephschorr]

@kartikaysaxena Checking in on this; I'd like to get it in but it has conflicts

[kartikaysaxena]

Hey @josephschorr sorry was busy at work; I have rebased and resolved the the merge conflicts and did a sanity on the changes. Let me know if anything else is needed, happy to help.