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

Fix context bugs #373

Merged
merged 12 commits into from
Feb 7, 2023
Merged

Fix context bugs #373

merged 12 commits into from
Feb 7, 2023

Conversation

cap10morgan
Copy link
Contributor

Fixes #370 & #371.

This is definitely a "simplest possible thing that could work" approach to #371, and specifically the implementation we decided on of moving the context from db flakes into the commits. So, for example, it leaves it in (-> db :schema :context) and (-> db :schema :context-str) which feels kind of like the wrong place now (there's a few hacks to make sure the vocab-flakes don't clobber it).

Also the imminent PR for #342 is going to conflict with this in some important ways, but I've promised to lead the effort to clean that up.

I also deleted some files that were deleted in the merge of #372 rather than update them to work with the changes in here.

@cap10morgan cap10morgan requested a review from a team February 7, 2023 18:52
@cap10morgan
Copy link
Contributor Author

I'll get those conflicts resolved shortly.

Copy link
Contributor

@bplatz bplatz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great to see. I'd like to have the context written as its own content-addressed file. Some contexts can be very large... but great first step.

Content-addressed also helps as often the same context is reused, so we only need to store it once.

I'll just comment here so others on the team can approve, but looks great to me.

[{:keys [conn] :as ledger} commit]
(go-try
(let [context (get commit (keyword const/iri-default-context))
stringify? (-> context keys first keyword?) ; (too?) simple check if we need to stringify the keys before storing
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think they should be JSON in the commit, so don't think this should ever be a keyword unless the JSON read function does recursive keywordizing, which maybe it does. Recursive keywordizing has given us many unintentional bugs, but if thats whats happening for now probably best to leave.

(let [context (get commit (keyword const/iri-default-context))
stringify? (-> context keys first keyword?) ; (too?) simple check if we need to stringify the keys before storing
context-str (if stringify?
(walk/stringify-keys context)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a simpler util/stringify-keys that I think would work better and fits this use case. Walk not only brings in a whole new namespace + its backing functions for a simple task, it also is more generic to apply to many data structures - where our internal function is a simple reduce designed for simple maps just like this.

[:rdfs/Class :id "http://www.w3.org/2000/01/rdf-schema#Class"]
[:rdf/type :id "http://www.w3.org/1999/02/22-rdf-syntax-ns#type"]
["fluree-default-context" :id "fluree-default-context"]
["fluree-default-context" :rdf/type :f/Context]
["fluree-default-context" :f/context "{\"schema\":\"http://schema.org/\",\"wiki\":\"https://www.wikidata.org/wiki/\",\"xsd\":\"http://www.w3.org/2001/XMLSchema#\",\"type\":\"@type\",\"rdfs\":\"http://www.w3.org/2000/01/rdf-schema#\",\"ex\":\"http://example.org/ns/\",\"id\":\"@id\",\"f\":\"https://ns.flur.ee/ledger#\",\"sh\":\"http://www.w3.org/ns/shacl#\",\"skos\":\"http://www.w3.org/2008/05/skos#\",\"rdf\":\"http://www.w3.org/1999/02/22-rdf-syntax-ns#\"}"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yay!!! So happy to see this gone!

@@ -62,7 +62,8 @@
{:extra-paths ["test" "dev-resources"]
:extra-deps {lambdaisland/kaocha {:mvn/version "1.71.1119"}
org.clojure/test.check {:mvn/version "1.1.1"}
com.magnars/test-with-files {:mvn/version "2021-02-17"}}
io.github.cap10morgan/test-with-files {:git/tag "v1.0.0"
:git/sha "9181a2e"}}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume a bug? Might be worth a comment, so in the future we know when/if we can revert to the main repo.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope. The explanation is in the commit message. I forked it to add a handy debugging feature (namely, keeping the tmp dir around after this goes out of scope). Given the age of at least one other PR upstream, I doubt it's worth the trouble to try to get it accepted upstream. Between that and the fact that it's strictly a dev / test dep, I wasn't going to worry about it too much.

Happy to move the fork to the Fluree GH org though, if anyone would prefer that. It probably does make more sense in this case.

@cap10morgan
Copy link
Contributor Author

This is great to see. I'd like to have the context written as its own content-addressed file. Some contexts can be very large... but great first step.

Content-addressed also helps as often the same context is reused, so we only need to store it once.

I'll just comment here so others on the team can approve, but looks great to me.

That is already in here! :) That's what f.d.json-ld.commit/link-context-to-commit does.

Seeing this when it fails:

WARN fluree.db.json-ld.vocab - "Invalid db default context, unable to parse: 150"

And the loaded context doesn't match the live one (missing the values set on the ledger)
I hope this doesn't screw up anyone else's contrast, but on my (solarized light) editor color scheme, I can't see the white text at all.
...in reify by making it use the same logic as transact.

Fixes #370
Copy link
Contributor

@zonotope zonotope left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🪟

...so we can use the {::test-with-files.tools/delete-dir false} option I added when debugging tests.
My editor thinks it should be one way, but it's wrong.
We should either do all of these like this or none of them (I vote none b/c passed-in fn args like this are harder to debug IMO). I did this once already in this branch but accidentally reverted it in a conflict resolution.
@cap10morgan cap10morgan merged commit 062f9b8 into main Feb 7, 2023
@cap10morgan cap10morgan deleted the fix/context-bug branch February 7, 2023 23:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Detection of ref->node vs. value flake is too simplistic in reify code
3 participants