ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: CREATE TABLE SQL command syntax
Date Wed, 12 Apr 2017 04:54:50 GMT
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>
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> 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>:
> > > 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> 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