You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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
load
ed 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.
The text was updated successfully, but these errors were encountered: