-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
feat(constraint_graph): make the constraint graph framework generic and move it into a separate crate #3071
Conversation
…nd move it into a separate crate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…s opposed to nodes
…aint-graphs-generic
393c34f
…rswitch_constraint_graph
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than that, looks good to me!
[package] | ||
name = "hyperswitch_constraint_graph" | ||
description = "Constraint Graph Framework for modeling Domain-Specific Constraints" | ||
version = "0.1.0" | ||
edition.workspace = true | ||
rust-version.workspace = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a license
and optionally, a readme
field?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will add the PR to the merge queue as @vspecky confirmed to add the license and readme in the next upcoming PR.
Type of Change
Description
This PR separates out and refactors the Euclid Knowledge Graph into the Constraint Graph in its own crate, and makes the Constraint Graph generic so it can work on custom key and value types as opposed to just the Euclid Key and Value types.
This will remove the dependency on Euclid when one needs to only use the Constraint Graph, plus the now generic nature of Constraint Graphs will allow them to be utilized for varied use cases other than routing.
Additional Changes
Motivation and Context
Making the constraint graph generic opens up the opportunity for other developers to adapt and use the constraint graph for their own usecases. There are many validation use cases currently in Hyperswitch that can be fulfilled by using Constraint Graphs, including but not limited to Connector domain validations, required field selection, etc.
How did you test it?
Unit tests for the
euclid
andkgraph_utils
crates. No specific API tests required.Euclid:
Kgraph_utils:
Checklist
cargo +nightly fmt --all
cargo clippy