-
Notifications
You must be signed in to change notification settings - Fork 168
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
Expose list_find
in the c api
#5848
Conversation
@@ -2624,6 +2664,13 @@ TEST_CASE("C API", "[c_api]") { | |||
size_t size; | |||
CHECK(checked(realm_list_size(bars.get(), &size))); | |||
CHECK(size == 2); | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A list of TypedLink is not officially supported. But there should be some way to find a destination object in a list of links. In C++ we support finding by ObjKey, but it looks like the C-API doesn't expose this type in a realm_value_t
for some reason. We should either convert TypedLink to ObjKey in realm_list_find
or we should support LnkLst::find_any
given a Mixed of type TypedLink. In either case, when converting from TypedLink to ObjKey, we'd need to check that the destination table matches.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think probably we should file a separate issue and add support for this stuff at some stage in C API too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just added a small fix, I think it is OK to sneak in here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, then we need to do this also for Sets
and Dictionaries
, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to do nothing for Dictionaries
. I added the implementation for Sets
src/realm.h
Outdated
/** | ||
* Find the value in the list passed as parameter. | ||
* @param value to search in the list | ||
* @param out_index the index where the value has been found |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this set to if the value hasn't been found?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
realm::not_found;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should document the actual value here to make it easier for consumers or alternatively, define it as a constant somewhere so that it can be referenced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can add a comment, but this is in line with all the other find APIs
src/realm/set.hpp
Outdated
found = real2virtual(found); | ||
|
||
auto find_obj_key = [this](ObjKey objkey) { | ||
size_t found = find(objkey); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This find method makes the translation to virtual index. Just use it directly below. This seems to have been an error before as well. Do we actually have a test involving this? I played around to verify my assumptions - may as well push my findings.
* @param out_found boolean that indicates whether the value is found or not | ||
* @return true if no exception occurred. | ||
*/ | ||
RLM_API bool realm_list_find(const realm_list_t*, const realm_value_t* value, size_t* out_index, bool* out_found); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need out_found
- seems like we can easily infer that from out_index
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes we do and I disagree on this proposal. For 2 reasons:
- finds for set has the same signature (and also most of the find APIs we have in the C API)
out_index
is of typesize_t
this means it can never be negative. If you assign -1 to signal that the value was not found, this index might beMAX_LIMIT(std::size_t)
which can be a valid index.
I would leave it as it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, realm::not_found
is std::size{-1}
. So in theory, we could get rid of the boolean. However, I would rather keep it as it is to keep it consistent.
src/realm.h
Outdated
/** | ||
* Find the value in the list passed as parameter. | ||
* @param value to search in the list | ||
* @param out_index the index where the value has been found |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should document the actual value here to make it easier for consumers or alternatively, define it as a constant somewhere so that it can be referenced.
|
||
size_t out_index = -1; | ||
bool found; | ||
CHECK(checked(realm_list_find(strings.get(), &a2, &out_index, &found))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These tests only seem to test the case where a value is found. Can we add a test where find
is called with a value that doesn't exist in the list?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was actually a test that was exercising the "not found" path, but we are sneaking in Mixed Links support as well. Let me add a test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I noticed we're also missing |
There are 2 versions of |
Good point - it's weird we have two of those. I'll file a new ticket to address that and add a single results_find method. |
…nification * origin/master: Stop forcing enums to be 64 bits unnecessarily clean up documentation of internal fields in config structs SyncConfig should be default constructible Traversal functions use IteratorControl values rather than true/false which is more expressive (#5857) Fix handling of 4-byte UTF8 values on Windows (#5803) Encode links in a way the server can understand (#5835) expose `Group::remove_table` in the C API (#5860) Disable auto refresh for old realm during migration (#5856) Expose `list_find` in the c api (#5848) Do not allow asymmetric tables in pbs (#5853) Refactor link tracing code (#5796) Expose `Obj::get_parent_object` in the C API (#5851) Update app.hpp (#5854) Fix appending to list ignores existing query (#5850)
What, How & Why?
Fixes: #5842
☑️ ToDos