IMO the right thing is not to divide between "us" and "them". We use H2 anyways and if we improve usability in H2, we automatically improve usability in Ignite.
Sergi 2017-02-06 11:27 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > Sergi, > > Cache creation function will be too complex without named parameters. As I > understand we have two options at the moment: > - Invest into H2 and add named parameters there, then use custom functions > in Ignite; > - Invest into Ignite and add custom "CREATE CACHE" parsing. > > CREATE CACHE doesn't appear to be extraordinary complex to me, especially > for the first release, where there will be no need to parse absolutely > every single property. So choosing between these two options my vote is for > putting efforts to Ignite rather than to H2. > > On Fri, Feb 3, 2017 at 5:56 PM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > Nope, but we can add this to H2 to make it compatible with Oracle [1] > > and/or PostgreSQL [2]. > > > > [1] > > https://logicalread.com/oracle-11g-named-parameters- > > in-sql-function-calls-mc02 > > [2] https://www.postgresql.org/docs/9.1/static/sql-syntax- > > calling-funcs.html > > > > Sergi > > > > 2017-02-03 17:41 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > > > > > Sergi, > > > > > > Does H2 support naming for function parameters? E.g. NEW_CACHE(backups: > > 1, > > > mode: PARTITIONED) > > > > > > On Fri, Feb 3, 2017 at 4:28 PM, Sergi Vladykin < > sergi.vlady...@gmail.com > > > > > > wrote: > > > > > > > Actually we do not support FULLTEXT indexes in SQL right now. Thus I > > > think > > > > we will have to postpone this feature anyways. > > > > > > > > I hope that H2 Mode will solve most of the problems here. But another > > > thing > > > > is that IMO we should avoid inventing any "too custom" SQL syntax. > For > > > > example I agree that we have to be able to create caches from SQL, > but > > I > > > > don't like the idea of inventing CREATE CACHE syntax. May be its > better > > > to > > > > have functions like the following: > > > > > > > > CALL NEW_CACHE(...); > > > > > > > > This is very straightforward and will allow us to avoid any problems > > with > > > > syntax parsing. > > > > > > > > Sergi > > > > > > > > 2017-01-30 12:47 GMT+03:00 Alexander Paschenko < > > > > alexander.a.pasche...@gmail.com>: > > > > > > > > > Dima, > > > > > > > > > > H2's grammar for CREATE INDEX currently does not allow expressing > all > > > > > that Ignite has in this field - say, I can't specify FULLTEXT index > > > > > types. (But, for clarity, I should also note that I don't see > > anything > > > > > else missing right away). > > > > > > > > > > On the other hand, if we want to enhance indexes someday, H2 may > not > > > > > be there to support our custom syntax. > > > > > > > > > > All in all, I believe that the moment for messing the custom syntax > > > > > will no doubt come, sooner or later, and we can't avoid it forever. > > So > > > > > all our attempts to avoid messing with it now just delay the moment > > > > > when we will simply have no choice and will have to come up with > > > > > something quick and dirty in a rush and hurry. > > > > > > > > > > Yes, Ignite mode for H2 probably could be a solution for parsing, > but > > > > > we have to keep in mind that compatibility mode in H2 is more than > > > > > syntax. And H2 folks will not likely be happy with just bunch of > > > > > random syntax changes that are otherwise irrelevant to RDBMS and > will > > > > > not be used by or implemented in H2 itself anyway. > > > > > > > > > > - Alex > > > > > > > > > > 2017-01-30 4:18 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org > >: > > > > > > On Fri, Jan 27, 2017 at 8:51 PM, Alexander Paschenko < > > > > > > alexander.a.pasche...@gmail.com> wrote: > > > > > > > > > > > >> Guys, > > > > > >> > > > > > >> And what would you say if I suggested that we implement custom > > > grammar > > > > > >> support with ANTLR? It allows you to describe pretty much any > > > grammar > > > > > >> in a declarative way, generates lexer and parser and then allows > > to > > > > > >> easily process parsed commands by implementing few (generated) > > > > > >> interfaces. Yesterday I gave it a try and it's really simple. > > > > > >> Downsides are use of generated code itself (I'm pretty sure > > someone > > > is > > > > > >> strongly against it) and relative wordiness of resulting code > > > written > > > > > >> manually. But this approach will no doubt save time and allow > any > > > > > >> extensions or changes in syntax in the future w/o worrying about > > H2 > > > or > > > > > >> anyone 3rd party. Thoughts? > > > > > >> > > > > > >> > > > > > > Alex, > > > > > > > > > > > > My preference would be to keep it simple, without introducing any > > > > custom > > > > > > grammar, at least for the "CREATE INDEX" command. I understand > the > > > need > > > > > for > > > > > > decoupling cache from schema, but it will take much longer to > > > > implement, > > > > > > and I would leave it for phase 2. In phase 1 we can focus on > > > delivering > > > > > > this much needed feature to the community as soon as possible. > > > > > > > > > > > > Do you agree? > > > > > > > > > > > > > > > > > >> - Alex > > > > > >> > > > > > >> 2017-01-27 21:56 GMT+03:00 Vladimir Ozerov < > voze...@gridgain.com > > >: > > > > > >> > My point was that we can avoid dependency on 3rd party > > developers > > > > for > > > > > >> this > > > > > >> > relatively simple logic. > > > > > >> > > > > > > >> > On Fri, Jan 27, 2017 at 8:07 PM, Dmitriy Setrakyan < > > > > > >> dsetrak...@apache.org> > > > > > >> > wrote: > > > > > >> > > > > > > >> >> On Fri, Jan 27, 2017 at 5:45 AM, Sergi Vladykin < > > > > > >> sergi.vlady...@gmail.com> > > > > > >> >> wrote: > > > > > >> >> > > > > > >> >> > H2 to some extent supports syntax (and quirks) from other > > > > > databases. > > > > > >> For > > > > > >> >> > example you can start it with MODE=MySQL and it will allow > > some > > > > > MySQL > > > > > >> >> > specific syntax to be handled. > > > > > >> >> > > > > > > >> >> > Having said that, IMO the most correct way to handle > > > non-standard > > > > > >> syntax > > > > > >> >> is > > > > > >> >> > to introduce H2 MODE=ApacheIgnite and put the needed > switches > > > > > there. > > > > > >> >> > > > > > > >> >> > Though this needs to be negotiated with H2 folks. > > > > > >> >> > > > > > > >> >> > > > > > >> >> Sergi, can you ask the H2 folks about this? I agree, this > > sounds > > > > like > > > > > >> the > > > > > >> >> most correct way. > > > > > >> >> > > > > > >> > > > > > > > > > > > > > > >
