Re: jdbc vs jdbc2 packages

Ticket: https://issues.apache.org/jira/browse/IGNITE-4922 — Denis > On Mar 30, 2017, at 7:06 PM, Denis Magda wrote: > > Folks, > > I had a chance to validate usability of both Ignite JDBC drivers at PGConf > USA today

Re: jdbc vs jdbc2 packages

Folks, I had a chance to validate usability of both Ignite JDBC drivers at PGConf USA today trying to connect to the cluster from the new JetBrains DataGrip SQL tool [1]. Together with JetBrains folks we agreed on the following or spotted the issues listed below. 1) Default JDBC driver, that

Re: jdbc vs jdbc2 packages

Val, Igniters, I still believe the thin client has a right for living. It’s ideal for use cases when someone attempts to connect to Ignite from a tool or some sort of interface and query the data or update it in non transactional fashion. A TCP/IP address as a connection string to the cluster

Re: jdbc vs jdbc2 packages

I'm against keeping legacy thin client because: - Having two ways to configure driver is unnecessary complication and very bad from usability standpoint. - It is much slower than client node, performance was the main driver behind its deprecation. What we should do, is improve usability of the

Re: jdbc vs jdbc2 packages

Denis, I completely agree that we should have a thin JDBC client. Can you file a ticket? On Wed, Mar 15, 2017 at 4:58 PM, Denis Magda wrote: > Frankly, during these two a couple of day I had a chance to play with Web > Console and Ignite JDBC driver. > > As many other users I

Re: jdbc vs jdbc2 packages

I generally like the idea of supporting thin JDBC clients. Often it is not feasible to start a client node on JDBC side. On Fri, Feb 10, 2017 at 1:04 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Yakov, > > There are two separate aspects that we can improve: > > 1. Message

Re: jdbc vs jdbc2 packages

Yakov, There are two separate aspects that we can improve: 1. Message routing as you described. I agree it can be useful in some scenarios and I definitely not against this feature, but honestly I haven't seen a lot of requests for this so far. 2. Server can initiate connection with client. This

Re: jdbc vs jdbc2 packages

Val, can you please explain your statement. You suggest users have port forwarding for dozens of nodes in their topologies so client can initiate connect to any of them? I don't think this is possible and routing seems to be the only possible option. --Yakov 2017-02-10 0:04 GMT+03:00 Valentin

Re: jdbc vs jdbc2 packages

Yakov, 1. Yes, I will file a ticket. 4. I meant that server can currently initiate connection with client, and that's the main problem here. Is there a way to avoid this? Message routing you're referring to can also be useful in some cases, but much less critical. -Val On Wed, Feb 8, 2017 at

Re: jdbc vs jdbc2 packages

Val, 1. Our clients should stop require persistent store implementation if they do not need it. Can you please file a ticket? I know you fixed some places already. As an idea I would keep everything in binary format until we really need it. Will that work? 2. We can try adding the very first step

Re: jdbc vs jdbc2 packages

"undeprecating" - lol :D Consider introducing @Un annotation which negates all annotations on the same level and below. I would probably agree with Val and Vova, but adding features to thin-client seems questionable to me. Is these possible: 1. avoid dependencies on client machine and require

Re: jdbc vs jdbc2 packages

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: -

Re: jdbc vs jdbc2 packages

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