While adding/updating/removing the edges/vertices, it is possible to have an auto version capability with per mutation update. initially, I tried the way mentioned in the post. But assume this should come from core feature by default it should be false. given an option for the user to change to true. and enable this feature to detect the change, if there is any create a version of it.
No sure what you mean, but I believe it’s not possible. Mutations are write operation. There’s nothing to establish such logic in it. At least for now.
You are free to change or add aliases to your predicates in Schema. Any time. Self-generation based on something arbitrary would be tricky to deal with.
Remember that Dgraph has Schema, Query language and Mutations (JSON or RDF). It would be hard work to control all this without breaking anything.
So it’s up to you to create a versioning approach.
Quoting GraphQL:
Versioning
While there’s nothing that prevents a GraphQL service from being versioned just like any other REST API, GraphQL takes a strong opinion on avoiding versioning by providing the tools for the continuous evolution of a GraphQL schema.
Why do most APIs version? When there’s limited control over the data that’s returned from an API endpoint, any change can be considered a breaking change, and breaking changes require a new version. If adding new features to an API requires a new version, then a tradeoff emerges between releasing often and having many incremental versions versus the understandability and maintainability of the API.
In contrast, GraphQL only returns the data that’s explicitly requested, so new capabilities can be added via new types and new fields on those types without creating a breaking change. This has lead to a common practice of always avoiding breaking changes and serving a versionless API.
Source: https://graphql.org/learn/best-practices/