Retrieve a `KeyedChain` directly from neo4j
Codecov Report
:x: Patch coverage is 98.30508% with 1 line in your changes missing coverage. Please review.
:white_check_mark: Project coverage is 80.55%. Comparing base (1ab4cdd) to head (76dffe2).
:warning: Report is 11 commits behind head on main.
| Files with missing lines | Patch % | Lines |
|---|---|---|
| alchemiscale/storage/statestore.py | 98.30% | 1 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## main #408 +/- ##
==========================================
- Coverage 80.89% 80.55% -0.34%
==========================================
Files 27 27
Lines 3806 3863 +57
==========================================
+ Hits 3079 3112 +33
- Misses 727 751 +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.
Do we need to sanitize scoped_key? I am not a neo4j wizard, but would the right escapes allow a user to pass in some arbitrary neo4j db quarry? I think because the format of the scope_key is very strict, it would be worth checking the key looks valid, it would even help a user realize they passed in a malformed key without having to get a weird "no records found" error and they might not realize why.
EDIT: I think sanitize is the wrong terminology (since that implies we would remove/escape stuff) instead we are looking to validate the key (has the right length and only the letters/numbers we expect)
Do we need to sanitize
scoped_key? I am not a neo4j wizard, but would the right escapes allow a user to pass in some arbitrary neo4j db quarry? I think because the format of thescope_keyis very strict, it would be worth checking the key looks valid, it would even help a user realize they passed in a malformed key without having to get a weird "no records found" error and they might not realize why.EDIT: I think sanitize is the wrong terminology (since that implies we would remove/escape stuff) instead we are looking to validate the key (has the right length and only the letters/numbers we expect)
@mikemhenry can you point where in this PR you are looking to sanitize scoped_key? I'm having trouble understanding where the concern is.
I thought this was an object a user created (where then they could pass in whatever they wanted for scoped_key but looking at how it all works, it gets validated a few different ways by the time it hits the state store, so we are good -- just thinking of this issue whenever we are doing db queries https://github.com/OpenFreeEnergy/alchemiscale/issues/259