-
Notifications
You must be signed in to change notification settings - Fork 991
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
Improved key handling when assigning with ':=' #2389
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2389 +/- ##
==========================================
+ Coverage 91.24% 91.29% +0.04%
==========================================
Files 62 62
Lines 11978 12023 +45
==========================================
+ Hits 10929 10976 +47
+ Misses 1049 1047 -2
Continue to review full report at Codecov.
|
I added a few more comments in the file at the top explaining the thinking here.
Sorry - I guess I broke it by removing I've added you as a project member so that you can create branches inside the main repo if you'd like. This will mean I can pull, test and push to your branch, rather than me using the online editor as I'm doing now. |
Thank you very much for the invitation! I am happy to join. |
And tidied up that section at the top with hopefully clearer comments.
Currently, we have to skip test numbers ending zero because, for example, if 1419.10 fails, it prints as 1419.1 the same as 1419.1 and we can't distinguish. Haven't thought of a solution yet. For now, I just think of it as a bit of culture/personality in the code, like missing unlucky number 13.
Thank you for cleaning up. I am still learning :) |
This closes #2372.
Now, when updating columns with :=, existing keys and indices are retained up to the first modified column (exclusive).
Example: key on x1, x2, x3 --> assignment on x2 --> key on x1.
The tests 1400 ff had to be modified since they were testing for the old behaviour.
Additional tests have been added to make sure, all cases are handled, also on empty data.tables.
I tested for C memory allocation problems with
R -d valgrind
and found no issues.There is an issue with a segmentataion fault on unloading the package but I discovered that this is a problem of the master (issue [#2388])
A small benchmark (code at the end of this post) shows that there is no speed penalty associated with the new implementation: