ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergi Vladykin <sergi.vlady...@gmail.com>
Subject Re: CREATE TABLE SQL command syntax
Date Wed, 12 Apr 2017 10:28:14 GMT
Sergey,

We've already discussed this and decided to have a cache per table, because
otherwise user will be forced to have unique keys across multiple
independent tables, which is bad.

Thus the idea with TABLESPACE does not really work for us.

Sergi

2017-04-12 13:15 GMT+03:00 Sergi Vladykin <sergi.vladykin@gmail.com>:

> I don't see how you make H2 Parser extendable, you will have to add plugin
> call to every *potentially* extendable place in it. In general this does
> not work. As H2 guy I would also reject patch like this.
>
> Sergi
>
> 2017-04-12 13:10 GMT+03:00 Alexander Paschenko <
> alexander.a.paschenko@gmail.com>:
>
>> Sergi,
>>
>> Please have a closer look at what I've written in my first post. I don't
>> see why we have to cling to H2 and its parsing modes all the time — after
>> all, we're just talking string processing now, aren't we? (Yes, complex
>> and
>> non trivial, but still.)
>>
>> What's wrong with idea of patching H2 to allow custom parsing? (With the
>> parsing itself living in Ignite code, obviously, not in H2.).
>>
>> What I propose is just to make H2's Parser class extendable and make H2
>> aware of its descendants via config params. And that's all with respect to
>> H2, nothing more.
>>
>> After that, on Ignite side we do all we want with our parser based on
>> theirs. It resembles story with custom types — first we make H2 extendable
>> in the way we need, then we introduce exact features we need on Ignite
>> side.
>>
>> — Alex
>>
>> среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:
>>
>> > It definitely makes sense to add a separate mode for Ignite in H2.
>> Though
>> > it is wrong to think that it will allow us to add any crazy syntax we
>> want
>> > (and it is actually a wrong idea imo), only the minor variations of the
>> > existing syntax. But this must be enough.
>> >
>> > I believe we should end up with something like
>> >
>> > CREATE TABLE person
>> > (
>> >   id INT PRIMARY KEY,
>> >   orgId INT AFFINITY KEY,
>> >   name VARCHAR
>> > )
>> > WITH "cfg:my_config_template.xml"
>> >
>> > Sergi
>> >
>> >
>> > 2017-04-12 7:54 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org
>> > <javascript:;>>:
>> >
>> > > Agree, the updated syntax looks better. One change though: KEY ->
>> PRIMARY
>> > > KEY.
>> > >
>> > > Sergi, what do you think?
>> > >
>> > > D.
>> > >
>> > > On Tue, Apr 11, 2017 at 9:50 PM, Pavel Tupitsyn <ptupitsyn@apache.org
>> > <javascript:;>>
>> > > wrote:
>> > >
>> > > > I think "WITH" syntax is ugly and cumbersome.
>> > > >
>> > > > We should go with this one:
>> > > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
>> > > > varchar, lastName varchar)
>> > > >
>> > > > All databases (i.e. [1], [2]) work this way, I see no reason to
>> invent
>> > > > something different and confuse the users.
>> > > >
>> > > > [1]
>> > > > https://docs.microsoft.com/en-us/sql/t-sql/statements/create
>> > > > -table-transact-sql#syntax-1
>> > > > [2] https://www.postgresql.org/docs/9.1/static/sql-createtable.html
>> > > >
>> > > > On Wed, Apr 12, 2017 at 6:12 AM, Alexander Paschenko <
>> > > > alexander.a.paschenko@gmail.com <javascript:;>> wrote:
>> > > >
>> > > > > Dmitry,
>> > > > >
>> > > > > For H2 it would be something like this - please note all those
>> > quotes,
>> > > > > commas and equality signs that would be mandatory:
>> > > > >
>> > > > > CREATE TABLE Person (id int, uid uuid, firstName varchar, lastName
>> > > > > varchar) WITH "keyFields=id,uuid","affinityKey=id"
>> > > > >
>> > > > > With suggested approach, it would be something like
>> > > > >
>> > > > > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
>> > > > > varchar, lastName varchar)
>> > > > >
>> > > > > While this may not look like a drastic improvement in this
>> particular
>> > > > > case, we someday most likely will want either an all-custom CREATE
>> > > > > CACHE command, or a whole bunch of new options for CREATE TABLE,
>> if
>> > we
>> > > > > decide not to go with CREATE CACHE - I personally think that
stuff
>> > > > > like
>> > > > >
>> > > > > CREATE TABLE ... WITH
>> > > > > "keyFields=id,uuid","affinityKey=id","cacheType=
>> > > partitioned","atomicity=
>> > > > > atomic","partitions=3"
>> > > > >
>> > > > > which will arise if we continue to try to stuff everything into
>> WITH
>> > > > > will just bring more ugliness with time, and that's not to mention
>> > > > > that new CREATE CACHE syntax will be impossible or relatively
>> hard to
>> > > > > introduce as we will have to approve it with H2 folks, and that's
>> how
>> > > > > it will be with any new param or command that we want.
>> > > > >
>> > > > > Allowing to plug custom parser into H2 (as we do now with table
>> > > > > engine) will let us introduce any syntax we want and focus on
>> > > > > usability and not on compromises and workarounds (which WITH
>> keyword
>> > > > > currently is).
>> > > > >
>> > > > > - Alex
>> > > > >
>> > > > > 2017-04-12 5:11 GMT+03:00 Dmitriy Setrakyan <
>> dsetrakyan@apache.org
>> > <javascript:;>>:
>> > > > > > Alexeander,
>> > > > > >
>> > > > > > Can you please provide an example of what the CREATE TABLE
>> command
>> > > > would
>> > > > > > look like if we use WITH syntax from H2 vs. what you are
>> proposing?
>> > > > > >
>> > > > > > D.
>> > > > > >
>> > > > > > On Tue, Apr 11, 2017 at 6:35 PM, Alexander Paschenko <
>> > > > > > alexander.a.paschenko@gmail.com <javascript:;>>
wrote:
>> > > > > >
>> > > > > >> Hello Igniters,
>> > > > > >>
>> > > > > >> Yup, it's THAT time once again as we haven't ultimately
>> settled on
>> > > > > >> anything with the subj. as of yet, but I believe that
now with
>> DDL
>> > > on
>> > > > > >> its way this talk can't be avoided anymore (sorry guys).
>> > > > > >>
>> > > > > >> The last time we talked about Ignite specific stuff
we need to
>> > have
>> > > in
>> > > > > >> CREATE TABLE (key fields list, affinity key, am I missing
>> > > anything?),
>> > > > > >> the simplest approach suggested by Sergi was that we
simply use
>> > WITH
>> > > > > >> part of H2's CREATE TABLE to pass stuff we need.
>> > > > > >>
>> > > > > >> This could work, but needless to say that such commands
would
>> look
>> > > > plain
>> > > > > >> ugly.
>> > > > > >>
>> > > > > >> I think we should go with custom syntax after all, BUT
not in a
>> > way
>> > > > > >> suggested before by Sergi (propose Apache Ignite mode
to H2).
>> > > > > >>
>> > > > > >> Instead, I suggest that we propose to H2 patch that
would allow
>> > > > > >> plugging in *custom SQL parser* directly based on theirs
(quite
>> > > > > >> elegant one) – I've had a look at their code, and
this should
>> not
>> > be
>> > > > > >> hard.
>> > > > > >>
>> > > > > >> Work on such a patch making syntax parsing overridable
would
>> take
>> > a
>> > > > > >> couple days which is not much time AND would give us
the
>> > opportunity
>> > > > > >> to introduce to Ignite virtually any syntax we wish
- both now
>> and
>> > > in
>> > > > > >> the future. Without worrying about compatibility with
H2 ever
>> > again,
>> > > > > >> that is.
>> > > > > >>
>> > > > > >> Thoughts? After we agree on this principally and after
H2 patch
>> > for
>> > > > > >> custom parsing is ready, we can roll our sleeves and
focus on
>> > syntax
>> > > > > >> itself.
>> > > > > >>
>> > > > > >> - Alex
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message