-
Notifications
You must be signed in to change notification settings - Fork 23
Update buffer element query functions #282
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
Changes from all commits
970a883
a4be6cf
97d02e4
26d136d
c1f6516
43cc8f1
86bb5a8
ee156df
b4c6106
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2912,12 +2912,30 @@ std::string libtiledb_query_status(XPtr<tiledb::Query> query) { | |
| // [[Rcpp::export]] | ||
| R_xlen_t libtiledb_query_result_buffer_elements(XPtr<tiledb::Query> query, | ||
| std::string attribute, | ||
| int32_t which=1) { | ||
| int32_t which = 1) { | ||
| auto nelements = query->result_buffer_elements()[attribute]; | ||
| R_xlen_t nelem = (which == 0 ? nelements.first : nelements.second); | ||
| return nelem; | ||
| } | ||
|
|
||
| // [[Rcpp::export]] | ||
| NumericVector libtiledb_query_result_buffer_elements_vec(XPtr<tiledb::Query> query, | ||
| std::string attribute, | ||
| bool nullable = false) { | ||
| if (nullable) { | ||
| auto nelem = query->result_buffer_elements_nullable()[attribute]; | ||
| auto vec = NumericVector( { | ||
| static_cast<double>(std::get<0>(nelem)), | ||
| static_cast<double>(std::get<1>(nelem)), | ||
| static_cast<double>(std::get<2>(nelem)) | ||
| }); | ||
| return vec; | ||
| } else { | ||
| auto nelem = query->result_buffer_elements()[attribute]; | ||
| return NumericVector( { static_cast<double>(nelem.first), static_cast<double>(nelem.second) }); | ||
| } | ||
| } | ||
|
|
||
| // [[Rcpp::export]] | ||
| int libtiledb_query_get_fragment_num(XPtr<tiledb::Query> query) { | ||
| if (query->query_type() != TILEDB_WRITE) { | ||
|
|
@@ -3208,6 +3226,23 @@ XPtr<tiledb::Query> libtiledb_query_set_condition(XPtr<tiledb::Query> query, | |
| return query; | ||
| } | ||
|
|
||
| // Note that the Array pointer returned here from a Query object is not owned and will not | ||
| // outlive the query object | ||
| // | ||
| // [[Rcpp::export]] | ||
| XPtr<tiledb::Array> libtiledb_query_get_array(XPtr<tiledb::Query> query, XPtr<tiledb::Context> ctx) { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we document somewhere that the return value from this function cannot outlive the query? (b/c it is non-owning).
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's a good question. Adding at least a code comment is very cheap and possibly illuminating. You may have seen that I shied away from promoting this more, and forcing its use into the size getter (in order to answer 'are we nullable?' and kept it simpler by asking for a bool from the users. It's not obvious to me yet what the best approach is. One other thing to consider is to simply budget another pointer in the S4 class for the query and keep the array pointer there (making it also clear that we access the array via the query that is associated with it) when we construct the query object.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think I missed where this is being used right now? I thought it was forward-looking. In any case, this:
sounds good to me. We do effectively the same thing in TileDB-Py, for similar reasons (I think there might be one bare call to get array on a C++
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (but if you prefer a code comment, that's fine too - I don't know what the intended usage is so keeping this "internal" seems fine)
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Current use is only in the test file. |
||
| auto arr = query->array(); | ||
| auto cptr = arr.ptr().get(); | ||
| return XPtr<tiledb::Array>(new tiledb::Array(*ctx.get(), cptr, false)); | ||
| } | ||
|
|
||
| // [[Rcpp::export]] | ||
| XPtr<tiledb::ArraySchema> libtiledb_query_get_schema(XPtr<tiledb::Query> query, | ||
| XPtr<tiledb::Context> ctx) { | ||
| auto arr = query->array(); | ||
| return libtiledb_array_schema_load(ctx, arr.uri()); // returns an XPtr<tiledb::ArraySchema> | ||
| } | ||
|
|
||
| /** | ||
| * Query Condition | ||
| */ | ||
|
|
||
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.
👍