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

Context set on ledger is not present when loaded from storage #371

Closed
cap10morgan opened this issue Feb 6, 2023 · 1 comment
Closed
Assignees
Labels
bug Something isn't working as expected
Milestone

Comments

@cap10morgan
Copy link
Contributor

cap10morgan commented Feb 6, 2023

While working on fluree/http-api-gateway#17 and #369 I noticed that when building up a ledger value from a conn in memory (e.g. in a REPL), you could set a default context on the conn and a context on the ledger. It would then merge this ledger context into the conn's default context and the ledger value would store that merged context in a :context key.

However, if you then came back and loaded that ledger later, on (your potentially new & different) conn's default context would be present. This is, I believe, the major issue motivating fluree/http-api-gateway#17 because the http-api-gateway loads the ledger on every request and they were setting contexts at ledger creation time rather than relying fully on the conn's default context.

In discussing how this should ideally work, Brian mentioned that he has never liked putting the context into flakes in the db anyway. So we decided to just move them to the commit metadata instead as the fix for this bug.

@cap10morgan cap10morgan self-assigned this Feb 6, 2023
@cap10morgan cap10morgan added the bug Something isn't working as expected label Feb 6, 2023
@cap10morgan cap10morgan added this to the 3.0.0-alpha1 milestone Feb 6, 2023
@cap10morgan
Copy link
Contributor Author

I almost implemented a check in here for an existing content-addressed context file and not rewriting it if it does exist (storage-method specific of course).

But it would represent a bigger refactoring of the storage methods than I wanted to tackle now. And, since it's sha-256 content-addressed too, I think this optimization would apply to commits too.

Should we write up another feature card to check for existing content-addressed keys in storage and not write them again when they do exist?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working as expected
Projects
None yet
Development

No branches or pull requests

1 participant