Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CABDss3j3HKDAzkeaet1xr6AD121zsCfZaOr2ppiXOSWJWEvBVw@mail.gmail.com>
References: <CAJhSPbriyMVto_GD1wQG0WXJJ09bUof2jju0hpH2_O1bzkdU1A@mail.gmail.com>
 <D77A1A7B-9864-447F-A1E2-1BF1BF418792@gridgain.com> <CA+eZwrF2YEZzAfB5u_7cyrqPrc4BNKBELT7Appw7pxNC3K8dSA@mail.gmail.com>
 <CA+0=VoX0ea6NySsM2qkX0kdVpeuivFX_ip9V=fdmC6-3=A=Oig@mail.gmail.com>
 <CA+eZwrF38d8RgaGQaibE9FnbM=KVPTEGTRSFeMaT=yPwnPLS=g@mail.gmail.com> <CABDss3j3HKDAzkeaet1xr6AD121zsCfZaOr2ppiXOSWJWEvBVw@mail.gmail.com>
From: Sergi Vladykin <sergi.vladykin@gmail.com>
Date: Thu, 21 Jul 2016 16:33:08 +0300
Message-ID: <CA+eZwrHQpNVOH4_gnVsM2FLdk_PMGCrHvUZqO7QYBQFHd72PMA@mail.gmail.com>
Subject: Re: IGNITE-2294 implementation details
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=94eb2c03ea661e120a0538255e0f
archived-at: Thu, 21 Jul 2016 13:33:54 -0000

--94eb2c03ea661e120a0538255e0f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I don't see why we need to start with DDL. We have table definitions with
key and value definitions in them, so what is the problem?

Sergi

On Thu, Jul 21, 2016 at 2:14 PM, Alexey Goncharuk <
alexey.goncharuk@gmail.com> wrote:

> For me the main question here is how we define Key and Value for a cache
> when using SQL interface. Unless we are going to re-architect the whole
> Ignite, it will still be a key-value storage in the first place, so
> whenever we do an INSERT, we must generate Key and Value. Given that valu=
es
> in INSERT are supposed to be fields of either Key or Value, this confuses
> me a lot.
>
> Maybe we should come up with DDL first?
>
> 2016-07-21 14:06 GMT+03:00 Sergi Vladykin <sergi.vladykin@gmail.com>:
>
> > No, this does not make sense.
> >
> > There is no upsert mode in databases. There are operations: INSERT,
> UPDATE,
> > DELETE, MERGE.
> >
> > I want to have clear understanding of how they have to behave in SQL
> > databases and how they will actually behave in Ignite in different
> > scenarios. Also I want to have clear understanding of performance
> > implications of each decision here.
> >
> > Anything wrong with that?
> >
> > Sergi
> >
> > On Thu, Jul 21, 2016 at 1:04 PM, Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> > wrote:
> >
> > > Serj, are you asking what will happen as of today? Then the answer to
> all
> > > your questions is that duplicate keys are not an issue, and Ignite
> always
> > > operates in **upsert** mode (which is essentially a *=E2=80=9Cput(=E2=
=80=A6)=E2=80=9D *method).
> > >
> > > However, the *=E2=80=9Cinsert=E2=80=9D* that is suggested by Alex wou=
ld delegate to
> > > *=E2=80=9CputIfAbsent(=E2=80=A6)=E2=80=9D*, which in database world m=
akes more sense. However,
> in
> > > this case, the *=E2=80=9Cupdate=E2=80=9D* syntax should delegate to *=
=E2=80=9Creplace(=E2=80=A6)=E2=80=9D*, as
> > > update should fail in case if a key is absent.
> > >
> > > Considering the above, a notion of =E2=80=9C*upsert=E2=80=9D* or =E2=
=80=9C*merge=E2=80=9D *operation is
> > > very much needed, as it will give a user an option to perform
> > > =E2=80=9Cinsert-or-update=E2=80=9D in 1 call.
> > >
> > > Does this make sense?
> > >
> > > D.
> > >
> > > On Wed, Jul 20, 2016 at 9:39 PM, Sergi Vladykin <
> > sergi.vladykin@gmail.com>
> > > wrote:
> > >
> > > > I'd prefer to do MERGE operation last because in H2 it is not
> standard
> > > ANSI
> > > > SQL MERGE. Or may be not implement it at all, or may be contribute
> ANSI
> > > > correct version to H2, then implement it on Ignite. Need to
> investigate
> > > the
> > > > semantics deeper before making any decisions here.
> > > >
> > > > Lets start with simple scenarios for INSERT and go through all the
> > > possible
> > > > cases and answer the questions:
> > > > - What will happen on key conflict in TX cache?
> > > > - What will happen on key conflict in Atomic cache?
> > > > - What will happen with the previous two if we use DataLoader?
> > > > - How to make these operations efficient (it will be simple enough =
to
> > > > implement them with separate put/putIfAbsent operations but probabl=
y
> we
> > > > will need some batching like putAllIfAbsent for efficiency)?
> > > >
> > > > As for API, we still will need to have a single entry point for all
> SQL
> > > > queries/commands to allow any console work with it transparently. I=
t
> > > would
> > > > be great if we will be able to come up with something consistent wi=
th
> > > this
> > > > idea on public API.
> > > >
> > > > Sergi
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Jul 20, 2016 at 2:23 PM, Dmitriy Setrakyan <
> > > > dsetrakyan@gridgain.com>
> > > > wrote:
> > > >
> > > > > Like the idea of merge and insert. I need more time to think abou=
t
> > the
> > > > API
> > > > > changes.
> > > > >
> > > > > Sergi, what do you think?
> > > > >
> > > > > Dmitriy
> > > > >
> > > > >
> > > > >
> > > > > On Jul 20, 2016, at 12:36 PM, Alexander Paschenko <
> > > > > alexander.a.paschenko@gmail.com> wrote:
> > > > >
> > > > > >> Thus, I suggest that we implement MERGE as a separate operatio=
n
> > > backed
> > > > > by putIfAbsent operation, while INSERT will be implemented via pu=
t.
> > > > > >
> > > > > > Sorry, of course I meant that MERGE has to be put-based, while
> > INSERT
> > > > > > has to be putIfAbsent-based.
> > > > > >
> > > > > > 2016-07-20 12:30 GMT+03:00 Alexander Paschenko
> > > > > > <alexander.a.paschenko@gmail.com>:
> > > > > >> Hell Igniters,
> > > > > >>
> > > > > >> In this thread I would like to share and discuss some thoughts
> on
> > > DML
> > > > > >> operations' implementation, so let's start and keep it here.
> > > Everyone
> > > > > >> is of course welcome to share their suggestions.
> > > > > >>
> > > > > >> For starters, I was thinking about semantics of INSERT. In
> > > traditional
> > > > > >> RDBMSs, INSERT works only for records whose primary keys don't
> > > > > >> conflict with those of records that are already persistent - y=
ou
> > > can't
> > > > > >> try to insert the same key more than once because you'll get a=
n
> > > error.
> > > > > >> However, semantics of cache put is obviously different - it do=
es
> > not
> > > > > >> have anything about duplicate keys, it just quietly updates
> values
> > > in
> > > > > >> case of keys' duplication. Still, cache has putIfAbsent
> operation
> > > that
> > > > > >> is closer to traditional notion of INSERT, and H2's SQL dialec=
t
> > has
> > > > > >> MERGE operation which corresponds to semantics of cache put.
> > Thus, I
> > > > > >> suggest that we implement MERGE as a separate operation backed
> by
> > > > > >> putIfAbsent operation, while INSERT will be implemented via pu=
t.
> > > > > >>
> > > > > >> And one more, probably more important thing: I suggest that we
> > > create
> > > > > >> separate class Update and corresponding operation update() in
> > > > > >> IgniteCache. The reasons are as follows:
> > > > > >>
> > > > > >> - Query bears some flags that are clearly redundant for Update
> > (page
> > > > > >> size, locality)
> > > > > >> - query() method in IgniteCache (one that accepts Query) and
> > query()
> > > > > >> methods in GridQueryIndexing return iterators. So, if we striv=
e
> to
> > > > > >> leave interfaces unchanged, we still will introduce some desig=
n
> > > > > >> ugliness like query methods returning empty iterators for
> certain
> > > > > >> queries, and/or query flags that indicate whether it's an upda=
te
> > > query
> > > > > >> or not, etc.
> > > > > >> - If some Queries are update queries, then continuous queries
> > can't
> > > be
> > > > > >> based on them - more design-wise ugly checks and stuff like
> that.
> > > > > >> - I'm pretty sure there's more I don't know about.
> > > > > >>
> > > > > >> Comments and suggestions are welcome. Sergi Vladykin, Dmitry
> > > > > >> Setrakyan, your opinions are of particular interest, please
> > advise.
> > > > > >>
> > > > > >> Regards,
> > > > > >> Alex
> > > > >
> > > >
> > >
> >
>

--94eb2c03ea661e120a0538255e0f--