Big +1 to Val, not only about JDBC, but about our overall approach to clients. Starting a node with "client=true" is: + Very reach feature set, which is cool - Tons of dependencies - Tons of threads
It would be very cool if we have a true thin client with small single JAR. It should have: - Failover - Load-balance - Optional server "stickyness" Once all these things are in place we will be able to provide the same API as in current client, but with predictable behavior and memory footprint. For instance our current client is not well-suited for running map-reduce (compute or SQL) because it moves large amount of data and processing to the client, which is potentially a slow desktop machine. On Tue, Feb 7, 2017 at 3:44 AM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > There are two implementations of JDBC driver - based on legacy thin client > (jdbc package) and on client node (jdbc2). The first one was deprecated > when we introduced the latter, but now I tend to think that this was not a > right decision. Thin client driver provides worse performance, but it's > much easier to use, never requires additional dependencies like Spring and > can be used from any remote machine. Probably we can consider undeprecating > it. > > -Val > > On Mon, Feb 6, 2017 at 2:02 AM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > Guys, > > > > We have 2 different packages: jdbc and jdbc2. Everything in jdbc is > > deprecated. Because of that new features like DML support were not added > > there. > > > > This seems to cause some problems to our users. Can someone clarify, did > we > > deprecated these classes wrongly and we have to continue developing them > or > > what? > > > > Sergi > > >
