[jira] [Commented] (KUDU-1944) Breaking changes best suited for a Kudu major release (i.e. 2.0)

["Andrew Wong (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KUDU-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16785095#comment-16785095 ] 

Andrew Wong commented on KUDU-1944:
-----------------------------------

Remove the various deprecated pieces of our public API.

Notably, any PB field that gets auto-generated in the Java client will expose a deprecated, but still useable method as a part of the public API. [{{DEPRECATED_range_predicates}}|https://gerrit.cloudera.org/c/12661/] in {{NewScanRequestPB}}, and the resulting {{addColumnRangePredicatesRaw}} and {{addColumnRangePredicate}} methods in {{AbstractKuduScannerBuilder}}, are an example of this.

> Breaking changes best suited for a Kudu major release (i.e. 2.0)
> ----------------------------------------------------------------
>
>                 Key: KUDU-1944
>                 URL: https://issues.apache.org/jira/browse/KUDU-1944
>             Project: Kudu
>          Issue Type: New Feature
>          Components: api, client, master, tserver
>    Affects Versions: 1.3.0
>            Reporter: Adar Dembo
>            Priority: Major
>
> I thought it might be useful to start a list of all Kudu features or additions that we suspect may be breaking (i.e. may break client API/ABI compatibility, wire compatibility, on-disk compatibility, etc.) and should be reserved for a Kudu major release, where we could expect to tolerate such breakages.
> Here are a few candidates off the top of my head.
> h4. Remove std:: classes from C++ client API
> The presence of std:: classes complicates maintenance of ABI compatibility w.r.t. libstdc++. Couple options here:
> * Replace std:: classes with simpler primitives (i.e. std::string -> void * + size_t).
> * Replace std:: classes with Kudu counterparts (i.e. std::string -> faststring).
> * Replace entire C++ API with a C-based API.
> * Add a C-based API but retain C++ API as header-only.
> I believe all of these break ABI compatibility and likely API compatibility too.
> h4. Rework Java client async API
> When we first released Kudu 1.0 we thought about stabilizing the async Java API (i.e. all public classes that start with Async), but decided against it because we had no good use cases. If we were to do that now, we'd most certainly be breaking ABI/API compatibility for anyone using it in its current form.
> h4. Rework status/error codes
> This one also comes up from time to time. It bemoans the coarse grainedness of Status' error codes and, depending on how its done, may break client ABI/API compatibility as well as wire compatibility.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)