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.

Sign up for GitHub

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

Jump to bottom

Question: kdbGets update behavior. #760

Closed
rautesamtr opened this issue May 30, 2016 · 2 comments
Closed

Question: kdbGets update behavior. #760

rautesamtr opened this issue May 30, 2016 · 2 comments
Assignees
@markus2330

Comments

@rautesamtr
Copy link
Contributor

The docu states:

Updates:
In the first run of kdbGet all requested (or more) keys are retrieved. On subsequent calls only the keys are retrieved where something was changed inside the key database. The other keys stay unchanged in the keyset, even if they were manipulated.

This made me assume that multiple calls would no overwrite changes to key values in the ks, that have not changed in the kdb. But calling kdbGet before kdbSet will reset any changes i made to the keyset. Is this specific behavior to the glib bindings?

But the docu also states:

The new retrieved keys will be appended using ksAppendKey().

and the docu says to ksAppendKey()

If the keyname already existed in the keyset, it will be replaced with the new key.

Which would explain the reset behavior of kdbGet() and i am probably misunderstanding the update statement from the docu. Does it mean the keys will not get changed, but their values will?
@markus2330
Copy link
Contributor

#706 improves the behaviour to something you would expect (@Namoshek and @KurtMi for details there)

Without the globalcache, kdbGet() will not manipulate the keys at all if no update is needed. So if you pass modified values, the values will stay modified, if you pass an empty keyset, the keyset will stay empty.

After you changed KDB using kdbSet(), it is similar to the situation where an update is needed, so the previous statement is irrelevant.

This behaviour is identical for every binding, it should only be influenced by plugins, and not by bindings.

I will update the docu to reflect this more clearly, please keep the issue open.

In the longer term, I think the globalcache should be default (see #690). Its behaviour is what you would expect. (And if it is not, we should discuss the globalcache behaviour.)

@rautesamtr rautesamtr mentioned this issue May 31, 2016
Closed
@markus2330 markus2330 self-assigned this May 31, 2016
@markus2330
Copy link
Contributor

The initial description is unclear. Which keyset was used for kdbGet and then kdbSet? Please reopen if the issue is still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@markus2330 markus2330

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@rautesamtr @markus2330