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 :
> Sergi,
>
> Cache creation function will be too complex without named parameters. A
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 ap
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 O
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
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 tha
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
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
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 pars
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. Yesterda
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
wrote:
> On Fri, Jan 27, 2017 at 5:45 AM, Sergi Vladykin
> wrote:
>
> > H2 to some extent supports syntax (and quirks) from other databases. For
On Fri, Jan 27, 2017 at 5:45 AM, Sergi Vladykin
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-s
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 ne
We should care about statements like this:
/* bla-bla */ CREATE TABLE
So naive "startsWith(...)" will not work in some scenarios.
:)
On Fri, Jan 27, 2017 at 7:06 PM, Vladimir Ozerov
wrote:
> Folks,
>
> H2 has nice and powerful SQL parser, and we pass all incoming SQL commands
> through it. How
Folks,
H2 has nice and powerful SQL parser, and we pass all incoming SQL commands
through it. However it doesn't support custom SQL syntax, which we are
likely to need in DDL at some point in future.
As DDL statements are relatively easy to parse comparing to SELECTs and
they do not involve optim
13 matches
Mail list logo
