Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
KeySet * ks1 = ksDup(ks); KeySet * interestingPart = ksCut (ks1, key); ksDel (ks1); // .... use interestingPart ....
or the alternative
KeySet * interestingPart = ksCut (ks, key); // .... use interestingPart .... ksAppend (ks, interestingPart);
are used quite frequently. We should add a counterpart to
// ksCopy would go better with ksCut, but it is already in use KeySet * ksExtract (const KeySet * ks, const Key * parentKey);
Thank you for creating this proposal!
Do you think ksExtract should be the function instead of ksDup? If it is only an idea for a new feature, we could also add it any later time (it would not be relevant for 1.0).
Btw. I wonder why you did not request for a
They could be merged, but then we would should optimise for the
I assume the function would take the keys below
It also prevents an optimisation that could be applied to
The end of the cut, could be found via
Exactly, and ksExtract is basically only
Thank you for looking into the details. But I think ksExtract is only an new feature and does not really help for 1.0.
The optimization for ksCut is a very good idea, can you maybe split this up in a second issue? But for 1.0 we also only should do optimizations which are really important (have use cases that are too slow otherwise.)
Not sure, what I want say here...
I'm not sure about "too slow otherwise", but
What we should do instead, to make handling of arrays easier, is introduce things like
Not sure what "hierarchically after" means. If you mean the next key after X (according to keyset order) that is not below X, then your example is wrong.
Nevertheless, I think
There are also further question with this approach: How does it combine with other option? What happens with cascading keys?
IMO we should stick with KISS and introduce a new function, if we need new functionality. Also this kind of lookup would probably be more useful, if it works with iterators/cursors/indices (whatever we want to call it). Then it could be used in an iteration to skip subtrees. I can't actually think of another use case right now, especially not one, where I just want a
Good to know! This is completely undocumented in doc/METADATA.ini where array is still an unused and only proposed feature.
Yes, I agree. But this is not essential for 1.0.
The key after the cut point (as you described above).
ksLookup already has a switch (or cascading if) for the options. So adding another option should not create a performance impact.
This we need to consider anyway.
Have you a suggestion for a name?
And there is some overhead for adding functions to a library. (Did you maybe already measured it?)
With the internal cursor
Then your example should have been one of:
ksLookupByName (ks, "user/test/abcd", KDB_O_HIERARCHY); // -> user/test/cutpoint ksLookupByName (ks, "user/test/cutpoint", KDB_O_HIERARCHY); // -> user/test/cutpoint1 ksLookupByName (ks, "user/test/cutpoint/a", KDB_O_HIERARCHY); // -> user/test/cutpoint1 ksLookupByName (ks, "user/test/cutpoint1", KDB_O_HIERARCHY); // -> user/test/xyz
Like I said, it would be a tiny performance impact, but
In terms of performance?
Don't we want to get rid of the internal cursor? (#2991 (comment))
Depends on what the function will actually do and whether is based on
In general, I think
Another function should be created for different kinds of search operations. It might be useful not only to find the next key on the same level, but also the previous one or maybe the first key above (the immediate parent may not be in the keyset) or below.
Yes, also performance, as the symbols need to be looked up when loading the libs. KDE hat huge problems with this but they also have an order of magnitude more libs.
Realistically, we will only be able to remove it from the public interface but not completely. Also the error messages need to be updated to contain the cause (@Piankero) because at the moment the cursor marks where the error happened.
Yes, it would be a cleaner interface. But then we also should remove KDB_O_POP which is actually the only left-over. If we get rid of this, we could avoid the argument to
And if we do this only in the public interface (and let the private interface more or less the same), we could even do it for 1.0.
Why? Where do we actually need the internal cursor?
I don't think this is always the case. In certain situations,
Maybe nowhere (except for the old system to pinpoint which key caused the error) but there are 271 occurrences of ksNext in the folder "src". And in these 271 places it is not enough to replace a function call but you actually need to rewrite loops. So there are also plenty ways of how bugs can be introduced.
In only about 10 places, so this should be manually doable in one day of work.