Conversation
|
|
||
| Query query = TV(nativeViewPtr)->get_parent().where(TV(nativeViewPtr)); | ||
| TableQuery* queryPtr = new TableQuery(query); | ||
| Query *queryPtr = new Query(std::move(TV(nativeViewPtr)->get_parent().where(TV(nativeViewPtr)))); |
There was a problem hiding this comment.
Any reason for changing this from a TableQuery to Query?
There was a problem hiding this comment.
TableQuery is created only for JNI and to wrap around the subtable. And it is deleted in this PR as well.
There was a problem hiding this comment.
Well, TableQuery was also introduced so we could do a deep copy of the query. @beeender are you certain that the core's Query constructor does a deep copy?
There was a problem hiding this comment.
It is calling move constructor and confirmed with core, it should work 🎉
|
Looks 👍 |
|
@cmelchior |
|
Other than what @kneth pointed, 👍 |
|
@beeender Please include motivation in the description besides just the title. |
|
@bmunkholm PR message updated. |
| LinkViewRef lvr = *lv; | ||
| Query query = lvr->get_target_table().where(LinkViewRef(lvr)); | ||
| TableQuery* queryPtr = new TableQuery(query); | ||
| Query *queryPtr = new Query(std::move(lvr->get_target_table().where(LinkViewRef(lvr)))); |
There was a problem hiding this comment.
The use of std::move here is unnecessary since lvr->get_target_table().where(LinkViewRef(lvd)) is already an rvalue.
6 participants
sub-table is not used in java-binding right now, and if it is going to be, the relevant logic might be more suitable in the object store.
Since we are moving to the object store, the sub-table related code needs to be cleaned anyway. So we do the clean up directly to the master branch to make the future PR easier to be reviewed.