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