+1 as well.
On Tue, Sep 11, 2018 at 10:27 AM Aleksey Yeschenko <aleksey@xxxxxxxxxx>
> If this is about inclusion in 4.0, then I support it.
> Technically this is *mostly* just a move+donation of some code from
> java-driver to Cassandra. Given how important this seemingly is to the
> board and PMC for us to not have the dependency on the driver, the sooner
> it’s gone, the better.
> I’d be +1 for committing to trunk.
> On 11 September 2018 at 14:43:29, Robert Stupp (snazy@xxxxxxxx) wrote:
> The patch is technically complete - i.e. it works and does its thing.
> It's not strictly a bug fix but targets trunk. That's why I started the
> On 09/11/2018 02:53 PM, Jason Brown wrote:
> > Hi Robert,
> > Thanks for taking on this work. Is this message a heads up that a patch
> > coming/complete, or to spawn a discussion about including this in 4.0?
> > Thanks,
> > -Jason
> > On Tue, Sep 11, 2018 at 2:32 AM, Robert Stupp <snazy@xxxxxxxx> wrote:
> >> In an effort to clean up our hygiene and limit the dependencies used
> >> UDFs/UDAs, I think we should refactor the UDF code parts and remove
> >> dependency to the Java Driver in that area without breaking existing
> >> UDFs/UDAs.
> >> A working prototype is in this branch: https://github.com/snazy/
> >> cassandra/tree/feature/remove-udf-driver-dep-trunk <
> >> https://github.com/snazy/cassandra/tree/feature/remove-
> >> udf-driver-dep-trunk> . The changes are rather trivial and provide
> >> backwards compatibility for existing UDFs.
> >> The prototype copies the necessary parts from the Java Driver into the
> >> source tree to org.apache.cassandra.cql3.functions.types and adopts
> >> usages - i.e. UDF/UDA code plus CQLSSTableWriter +
> >> The latter two classes have a reference to UDF’s UDHelper and had to
> >> changed as well.
> >> Some functionality, like type parsing & handling, is duplicated in the
> >> code base with this prototype - once in the “current” source tree and
> >> for UDFs. However, unifying the code paths is not trivial, since the
> >> sandbox prohibits the use of internal classes (direct and likely
> >> dependencies).
> >> Robert
> >> —
> >> Robert Stupp
> >> @snazy
> Robert Stupp
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx