Re: IGNITE-2294 implementation details

Dmitriy, I've updated the issue with current state of work and proposal for data streamer use, please have a look/advise. - Alex 2016-08-04 21:16 GMT+03:00 Alexander Paschenko : > Sergi, > > OK, all fixed, there's no trace of update operations in public API now,

Re: IGNITE-2294 implementation details

Sergi, OK, all fixed, there's no trace of update operations in public API now, thanks. Will update doc and issue shortly. - Alex 2016-08-04 12:32 GMT+03:00 Sergi Vladykin : > Ok, it is not a problem for us if we will not fail fast on wrong number > of arguments, but

Re: IGNITE-2294 implementation details

Ok, it is not a problem for us if we will not fail fast on wrong number of arguments, but will fail on the first query execution. Lets just drop this argument counting. We should not show SqlFieldsQuery.isQuery on public API if it is useless for the end users. If this stuff is needed for Jdbc we

Re: IGNITE-2294 implementation details

Sergi, > Why do we need to count query arguments? Can anyone clarify? Say, to make parameter index checks early like all major vendors do. That's why they are counted now. > Also about new public APIs. I don't see why we need SqlFieldsQuery.isQuery, > looks like it has to be optional, so it will

Re: IGNITE-2294 implementation details

About new public APIs 2. QueryCursor.isResultSet makes sense only for SqlFieldsQuery only in Jdbc. Thus it must be private on QueryCursorEx like fieldsMeta() for example. All in all, there should be no changes on public API at this point. Sergi 2016-08-04 9:05 GMT+03:00 Sergi Vladykin

Re: IGNITE-2294 implementation details

Also about new public APIs. I don't see why we need SqlFieldsQuery.isQuery, looks like it has to be optional, so it will only confuse users. Sergi 2016-08-04 9:00 GMT+03:00 Sergi Vladykin : > Why do we need to count query arguments? Can anyone clarify? > > Sergi > >

Re: IGNITE-2294 implementation details

Why do we need to count query arguments? Can anyone clarify? Sergi 2016-08-04 5:07 GMT+03:00 Alexey Kuznetsov : > About arguments number. I see following options here: > 1. Somehow use H2 engine to parse SQL string and check results. > 2. Use some other parsing library

Re: IGNITE-2294 implementation details

About arguments number. I see following options here: 1. Somehow use H2 engine to parse SQL string and check results. 2. Use some other parsing library instead of H2 but this will bring one more dependency to Ignite. 3. Write some simple parser by ourselves .

Re: IGNITE-2294 implementation details

Alex, See my comments below. -Val On Wed, Aug 3, 2016 at 5:47 AM, Alexander Paschenko < alexander.a.pasche...@gmail.com> wrote: > Guys, > > I have few questions about current state of the art regarding JDBC driver. > > First: in JdbcPreparedStatement, we determine number of arguments > simply

Re: IGNITE-2294 implementation details

Folks, OK, I have one thing to clarify about Statement.getResultSet: its javadoc says that it "should be called only once per result", so setting field to null every one and then is starting to make sense. However, this "should" word does not tell us what we have to do if the method gets called

Re: IGNITE-2294 implementation details

Guys, I have few questions about current state of the art regarding JDBC driver. First: in JdbcPreparedStatement, we determine number of arguments simply by counting question mark symbols. What if query string contains a string literal with question mark in it? It seems like a bug to me.

Re: IGNITE-2294 implementation details

On Tue, Aug 2, 2016 at 2:21 PM, Alexander Paschenko < alexander.a.pasche...@gmail.com> wrote: > Dmitriy, > > Sorry, link access fixed, please check now. > Will sum up current status on issue page, meanwhile links to both docs are > there. > Thanks! I have comments, but I will wait till your list

Re: IGNITE-2294 implementation details

Dmitriy, Sorry, link access fixed, please check now. Will sum up current status on issue page, meanwhile links to both docs are there. — Alex 2 авг. 2016 г. 10:51 PM пользователь "Dmitriy Setrakyan" < dsetrak...@apache.org> написал: > Alex, > > Can you please also make me happy and put all your

Re: IGNITE-2294 implementation details

Alex, Can you please also make me happy and put all your design into the ticket instead of sending it around in emails? On top of that, the link you provided is protected. I cannot access it. D. On Tue, Aug 2, 2016 at 8:24 AM, Alexander Paschenko < alexander.a.pasche...@gmail.com> wrote: > I

Re: IGNITE-2294 implementation details

I have pushed "zero" version of JDBC updates support, currently without batching (working on it). Sergi, also to make you happy here's another doc with changes to public API: http://goo.gl/FvGKUs - Alex 2016-08-01 20:06 GMT+03:00 Sergi Vladykin : > Ok, I think you don't

Re: IGNITE-2294 implementation details

Ok, I think you don't really understand what public API really is, so let me clarify. What you have described are all internal classes, public API is what end user will see and work with, like Ignite, IgniteCache, QueryCursor, etc... All the internal changes do not require any special discussion,

Re: IGNITE-2294 implementation details

Alexey, can you attach this document to the ticket, or better yet, just copy it there? On Mon, Aug 1, 2016 at 8:14 AM, Alexander Paschenko < alexander.a.pasche...@gmail.com> wrote: > Guys, > > Here's documented version of current API changes - it's quite modest > https://goo.gl/Y6Cv1b > > - Alex

Re: IGNITE-2294 implementation details

Guys, Here's documented version of current API changes - it's quite modest https://goo.gl/Y6Cv1b - Alex 2016-07-28 20:34 GMT+03:00 Alexander Paschenko : > Sergi, > > OK, I've done it as you said, thanks. > Now working on binary marshaller support. > > - Alex > >

Re: IGNITE-2294 implementation details

Sergi, OK, I've done it as you said, thanks. Now working on binary marshaller support. - Alex 2016-07-28 9:08 GMT+03:00 Sergi Vladykin : > I had a quick look at the PR. > > I don't like this @QueryCacheKey and setKeyProp method on public API. They > solve nothing but

Re: IGNITE-2294 implementation details

I had a quick look at the PR. I don't like this @QueryCacheKey and setKeyProp method on public API. They solve nothing but add complexity and make key to be stored twice in cache, which is wrong. Please remove this. If you want to do some public API changes you have to discuss them publicly

Re: IGNITE-2294 implementation details

Sergi, I've made changes to the API according to your valuable recommendations, thank you very much for giving them. Please refer to PR to see current state of the work. Will surely look into ODBC, .NET and Visor. Though they will most likely have to support a new feature rather than considerably

Re: IGNITE-2294 implementation details

Please don't forget about ODBC, .NET and Visor. They all have to work in the same way. Sergi 2016-07-27 14:15 GMT+03:00 Alexander Paschenko < alexander.a.pasche...@gmail.com>: > OK, I've found that bold cast to QueryCursor in IgniteCacheProxy > and had a look at how SqlFieldsQuery is used in

Re: IGNITE-2294 implementation details

OK, I've found that bold cast to QueryCursor in IgniteCacheProxy and had a look at how SqlFieldsQuery is used in JDBC driver. Thanks. - Alex 2016-07-27 13:02 GMT+03:00 Sergi Vladykin : > Where did you see R in SqlFieldsQuery? > > Sergi > > 2016-07-27 12:59 GMT+03:00

Re: IGNITE-2294 implementation details

Where did you see R in SqlFieldsQuery? Sergi 2016-07-27 12:59 GMT+03:00 Alexander Paschenko < alexander.a.pasche...@gmail.com>: > Sergi, > > But current signature of query() method returns not just some > iterator, but rather iterator of R which is type param of Query - > i.e., we won't be able

Re: IGNITE-2294 implementation details

Sergi, But current signature of query() method returns not just some iterator, but rather iterator of R which is type param of Query - i.e., we won't be able to return an int inside a QueryCursor. At least without API change (signature of query() method will have to be changed to drop

Re: IGNITE-2294 implementation details

Exactly. This will allow our Jdbc driver to work transparently. Sergi 2016-07-27 12:40 GMT+03:00 Alexander Paschenko < alexander.a.pasche...@gmail.com>: > Sergi, > > You wrote: > > I'd prefer to return the same information, so it will not be empty > > Do you mean return iterator with single

Re: IGNITE-2294 implementation details

Sergi, You wrote: > I'd prefer to return the same information, so it will not be empty Do you mean return iterator with single element that denotes number of rows? Dmitriy, You wrote: > What is the ticket number for this. Is the new API documented there? Overall issue number is 2294. There's

Re: IGNITE-2294 implementation details

What is the ticket number for this. Is the new API documented there? On Tue, Jul 26, 2016 at 11:36 AM, Sergi Vladykin wrote: > I don't see anything ugly in empty iterator, sorry if I insulted your taste > of beauty. > > If you will take a look at Jdbc, you will see

Re: IGNITE-2294 implementation details

I don't see anything ugly in empty iterator, sorry if I insulted your taste of beauty. If you will take a look at Jdbc, you will see that Statement.executeUpdate method returns number of updated rows, I'd prefer to return the same information, so it will not be empty (beauty is restored!). Sergi

Re: IGNITE-2294 implementation details

I see your point. But what about my concerns from initial post? Particularly about signatures of existing methods? I personally don't like an option of query() method always returning an empty iterator for any non-select query, it seems ugly design wise. - Alex 2016-07-26 18:15 GMT+03:00 Sergi

Re: IGNITE-2294 implementation details

I don't like any pre-parsing, especially with some libraries other than H2. H2 itself has enough quirks to multiply it on quirks of another library. This is exactly what I was talking about - we need some single entry point on API for all the SQL commands and queries. Thats why I suggested

Re: IGNITE-2294 implementation details

Guys, I would like to advance the discussion further. There's one quite important question that arose based on current state of work on this issue. If we use some kind of interactive console, like Visor, then how should it know whether SQL query it is requested to execute returns a result set or

Re: IGNITE-2294 implementation details

OK, then using your analogy, the current behavior in Ignite is MERGE for the most part. My preference is that Ignite SQL should work no different from traditional databases, which means: - INSERT is translated into *putIfAbsent()* call in Ignite - UPDATE is translated into *replace()* call in

Re: IGNITE-2294 implementation details

I agree. It looks like we first of all need some algorithm of key generation for new objects, and it does not necessarily have to be involved with DDL. The first suggestion that comes to my mind on that matter is, obviously, marking some method of the class persisted with magical annotation - so

Re: IGNITE-2294 implementation details

Suppose I have a PersonKey {int id;} class and Person {@SqlQueryField int id; @SqlQueryField String name; @SqlQueryField int age;} class. How would an insert statement look like? INSERT INTO Person (_key, _val) values (...) INSERT INTO Person (_key, _val, id, name, age) values (...) -> Obviously

Re: IGNITE-2294 implementation details

I don't see why we need to start with DDL. We have table definitions with key and value definitions in them, so what is the problem? Sergi On Thu, Jul 21, 2016 at 2:14 PM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > For me the main question here is how we define Key and Value for a

Re: IGNITE-2294 implementation details

For me the main question here is how we define Key and Value for a cache when using SQL interface. Unless we are going to re-architect the whole Ignite, it will still be a key-value storage in the first place, so whenever we do an INSERT, we must generate Key and Value. Given that values in INSERT

Re: IGNITE-2294 implementation details

No, this does not make sense. There is no upsert mode in databases. There are operations: INSERT, UPDATE, DELETE, MERGE. I want to have clear understanding of how they have to behave in SQL databases and how they will actually behave in Ignite in different scenarios. Also I want to have clear

Re: IGNITE-2294 implementation details

I'd prefer to do MERGE operation last because in H2 it is not standard ANSI SQL MERGE. Or may be not implement it at all, or may be contribute ANSI correct version to H2, then implement it on Ignite. Need to investigate the semantics deeper before making any decisions here. Lets start with simple

Re: IGNITE-2294 implementation details

Like the idea of merge and insert. I need more time to think about the API changes. Sergi, what do you think? Dmitriy On Jul 20, 2016, at 12:36 PM, Alexander Paschenko wrote: >> Thus, I suggest that we implement MERGE as a separate operation backed by >>

Re: IGNITE-2294 implementation details

> Thus, I suggest that we implement MERGE as a separate operation backed by > putIfAbsent operation, while INSERT will be implemented via put. Sorry, of course I meant that MERGE has to be put-based, while INSERT has to be putIfAbsent-based. 2016-07-20 12:30 GMT+03:00 Alexander Paschenko

IGNITE-2294 implementation details

Hell Igniters, In this thread I would like to share and discuss some thoughts on DML operations' implementation, so let's start and keep it here. Everyone is of course welcome to share their suggestions. For starters, I was thinking about semantics of INSERT. In traditional RDBMSs, INSERT works