[
https://issues.apache.org/jira/browse/KUDU-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16724448#comment-16724448
]
Adar Dembo commented on KUDU-1563:
----------------------------------
bq. What would be implications be if we could not do this in a backwards
compatible way?
It really depends on the incompatibility itself. IIRC, your draft adds a new
data member to {{KuduWriteOperation}}. This class is allocated by
libkudu_client.so via calls like {{KuduTable::NewInsert}}, and, most of the
time, deallocated by libkudu_client.so after it has taken ownership of the
operation in {{KuduSession::Apply}} and sent it on the wire. However, if the
operation failed, it'll be assigned to a {{KuduError}} and passed back to the
third party application, and the application can choose to take ownership of it
via {{KuduError::release_failed_op}}. At that point, the application is on the
hook for deallocating it, and if the application and libkudu_client.so don't
agree on the size and layout of the class, memory will get corrupted by the
deallocation.
In short, the severity and impact of the incompatibility varies on a case by
case basis, and is pretty difficult to assess thoroughly, which is why I'd err
on the side of either "don't do it", or "do it, and rev the client SONAME's
major version to express the incompatibility".
bq. I am not sure how to solve the PIMPL'ed issue either but I am happy to
investigate.
If you could isolate the changes to just new classes/subclasses (i.e. just a
new {{KuduInsertIgnore}} subclass of {{KuduWriteOperation}}), then you'd be in
the clear.
Barring that, you could implement new variants of {{KuduWriteOperation}} and
friends that are PIMPL'ed, and modify the rest of the client APIs to support
them alongside the existing variant. Users of the C++ client will need to
change their code to use the new variants, but it'll be completely safe from a
backwards compatibility perspective.
The [KDE community wiki page on the
subject|https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B]
has much more useful insight and some examples too.
> Add support for INSERT IGNORE
> -----------------------------
>
> Key: KUDU-1563
> URL: https://issues.apache.org/jira/browse/KUDU-1563
> Project: Kudu
> Issue Type: New Feature
> Reporter: Dan Burkert
> Assignee: Brock Noland
> Priority: Major
> Labels: newbie
>
> The Java client currently has an [option to ignore duplicate row key errors|
> https://kudu.apache.org/apidocs/org/kududb/client/AsyncKuduSession.html#setIgnoreAllDuplicateRows-boolean-],
> which is implemented by filtering the errors on the client side. If we are
> going to continue to support this feature (and the consensus seems to be that
> we probably should), we should promote it to a first class operation type
> that is handled on the server side. This would have a modest perf.
> improvement since less errors are returned, and it would allow INSERT IGNORE
> ops to be mixed in the same batch as other INSERT, DELETE, UPSERT, etc. ops.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
