Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
From: Denis Magda <dmagda@apache.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: CREATE TABLE usage from Java API, .NET, C++
Date: Thu, 31 Aug 2017 14:37:30 -0700
References: <AE409B12-D5C0-46D8-B856-26F9B3875787@apache.org>
 <CABuYRcpx22rw_9vkZCH1SqoSKm=k2HHM9TY5b-8-fsbB4F7NaQ@mail.gmail.com>
 <CAGt6o8=yt6DEF9iu96r1uaN-uq4rCXv232XnHfQot3msQKU6tg@mail.gmail.com>
To: dev@ignite.apache.org
In-Reply-To: <CAGt6o8=yt6DEF9iu96r1uaN-uq4rCXv232XnHfQot3msQKU6tg@mail.gmail.com>
Message-Id: <1CCB785A-0CB4-4C16-A177-121ACD35058B@apache.org>
archived-at: Thu, 31 Aug 2017 21:37:34 -0000

I knew we discussed this some day ago. Put a reference to this =
discussion into the ticket. It=E2=80=99s a good example of a usability =
issue we can solve with the new API.

=E2=80=94
Denis

> On Aug 30, 2017, at 2:51 AM, Vladimir Ozerov <vozerov@gridgain.com> =
wrote:
>=20
> Folks,
>=20
> Please see this [1] and this [2].
>=20
> [1]
> =
http://apache-ignite-developers.2346864.n4.nabble.com/Rethink-native-SQL-A=
PI-in-Apache-Ignite-2-0-td14335.html
> [2] https://issues.apache.org/jira/browse/IGNITE-4701
>=20
> On Wed, Aug 30, 2017 at 3:10 AM, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>=20
>> Ideally, SQL API has to be completely decoupled from cache API. =
Otherwise
>> we will keep getting issues like this.
>>=20
>> let's introduce top level API (IgniteSql?) and add everything there.
>>=20
>> -Val
>>=20
>> On Tue, Aug 29, 2017 at 7:47 PM Denis Magda <dmagda@apache.org> =
wrote:
>>=20
>>> Igniters,
>>>=20
>>> Not sure we discussed this before, so let me start a new thread.
>>>=20
>>> It=E2=80=99s claimed the command is supported from native Java, =
.NET, C++ APIs
>> but
>>> I had hard time trying to use it from there. Imagine this simple
>> statement
>>> to be called from Java source code:
>>>=20
>>> SqlFieldsQuery query =3D new SqlFieldsQuery(
>>>    "CREATE TABLE City (" +
>>>        " id LONG PRIMARY KEY, name VARCHAR)" +
>>>        " WITH \"template=3Dreplicated\"");
>>>=20
>>> *cache*.query(query).getAll();
>>>=20
>>> The CT command will be recognized but the *cache* is not the City =
cache.
>>> It=E2=80=99s some other cache existed prior the query execution.
>>>=20
>>> In my scenario I=E2=80=99ve planned to show how to configure the =
schema from
>>> scratch on an empty cluster and had to apply the following =
workaround
>>> instantiating a dummy cache:
>>>=20
>>> IgniteCache cache =3D ignite.getOrCreateCache(new
>>> CacheConfiguration<>("default").setIndexedTypes(Long.class,
>>>    Long.class).setSqlSchema("PUBLIC"));
>>>=20
>>>=20
>>> How do we want to improve this poor experience? My options are:
>>>=20
>>> 1) Introduce some static API (cache-reference-free) method for =
quiries
>>> like that.
>>> 2) Deploy the cache prior that call and pass its name into =
=E2=80=9CWITH=E2=80=9D
>>> statement.
>>>=20
>>> =E2=80=94
>>> Denis
>>=20