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
{{ message }}
This repository was archived by the owner on Feb 16, 2025. It is now read-only.
The spec plugin isn't completely conformant with what should be done in the spec hook. When implementig the hook, we decided to not waste too much time on it, just that the basisc work.
There can be different settings for the conflict handling
This can probably be removed
Yes, all the conflict handling settings should be removed entirely. During get all conflicts should be warnings during set they should be errors (unless @markus2330 thinks some conflicts should never be errors). That part could be handled from the libelektra-kdb side with the "error blocking trick", so the spec would be the same.
neither assign/condition nor default are processed in set
Not sure about assign/condition and whether we actually want to keep that (@markus2330 ?), but default should definitely be processed in set. See also #4484 (comment)
set operation sets internal/spec/remove on array
set removes internal/spec/array/validated
set does this thing here, I'm not sure what it is
All of the stuff related to array handling is very complicated and weird. Part of the weirdness comes from the fact that on master the spec plugin is only called once during kdbSet and somehow there should still be validation during kdbSet, but also spec should cleanup the copied data (obviously not possible).
However, please don't waste time on this. Like I said already: Just try to imitate what spec does on master. The existing tests obviously also expect this behaviour. Once that is done and merged, you can create another PR with the actual updates for spec (probably after new-backend is merged in master).
Another important thing is that default:/ keys should be processed in the poststorage phase of kdbGet, currently the are temporarily cut out during that phase.
I mark this stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions 💖
I closed this now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue.
Thank you for your contributions 💖
The spec plugin isn't completely conformant with what should be done in the spec hook. When implementig the hook, we decided to not waste too much time on it, just that the basisc work.
Yes, all the conflict handling settings should be removed entirely. During
get
all conflicts should be warnings duringset
they should be errors (unless @markus2330 thinks some conflicts should never be errors). That part could be handled from thelibelektra-kdb
side with the "error blocking trick", so thespec
would be the same.Not sure about
assign/condition
and whether we actually want to keep that (@markus2330 ?), butdefault
should definitely be processed inset
. See also #4484 (comment)All of the stuff related to array handling is very complicated and weird. Part of the weirdness comes from the fact that on
master
thespec
plugin is only called once duringkdbSet
and somehow there should still be validation duringkdbSet
, but alsospec
should cleanup the copied data (obviously not possible).See also #2700 and #4061
However, please don't waste time on this. Like I said already: Just try to imitate what
spec
does onmaster
. The existing tests obviously also expect this behaviour. Once that is done and merged, you can create another PR with the actual updates forspec
(probably afternew-backend
is merged inmaster
).Originally posted by @kodebach in #4495 (comment)
The text was updated successfully, but these errors were encountered: