Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
Content-Type: text/plain;
	charset=koi8-r
Mime-Version: 1.0 (1.0)
Subject: Re: Enums and SQL queries
From: Dmitriy Setrakyan <dsetrakyan@gridgain.com>
In-Reply-To: <CA+eZwrF3=K1Y9KgpT3jkGoHwO1nRrTfdYvwcpVzxP=q+3jApkQ@mail.gmail.com>
Date: Wed, 27 Jul 2016 15:51:39 -0400
Cc: Valentin Kulichenko <valentin.kulichenko@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE1875AA-FF27-4419-9647-E220CBF0995E@gridgain.com>
References: <CABuYRcqEL5E4uX6qtuw=qAdewyaXJuXLgNj-fVTz7Wa-Mewh2w@mail.gmail.com> <CA+eZwrEn00SKuOCrqfRCj4gpEGjKWh0TJCu32_jniqiOdheQqA@mail.gmail.com> <CABuYRco8qp9WrCpazHRSdSNfK+pxck-+dg4OxCPTiV0AEpTwWw@mail.gmail.com> <CA+eZwrHde3mBDgY6BUO__j=xq+f9gVo9OZtngPhu=3VxZy-DRg@mail.gmail.com> <CA+0=VoWFVcpYQAVTsgCXMvdARu+85S0ja5yDmWtYpmo5sdjTeA@mail.gmail.com> <CA+eZwrE1Z=8Hyk3k7jRQgUUuGnGFoW9UPM3MoZpor_O_L8NRTw@mail.gmail.com> <CA+0=VoU1H4D+d4wLZr0yi62ab4Ef2RqN9sE=zw-iRdjAZ4QrMA@mail.gmail.com> <CA+eZwrF3=K1Y9KgpT3jkGoHwO1nRrTfdYvwcpVzxP=q+3jApkQ@mail.gmail.com>
To: dev@ignite.apache.org
archived-at: Wed, 27 Jul 2016 19:51:47 -0000

Sorry, Sergi. What I meant is to file a ticket with the design you suggested=


Dmitriy


> On Jul 27, 2016, at 9:18 AM, Sergi Vladykin <sergi.vladykin@gmail.com> wro=
te:
>=20
> I don't see how this can work to file a ticket, could you please give more=

> details?
>=20
> Sergi
>=20
> 2016-07-27 15:50 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:
>=20
>> Sergi, I still thinks my solution works or can be made to work. In the
>> example you provided, you can choose to return either String or Enum as t=
he
>> query result. However, this is not a clean solution, I agree, but could b=
e
>> a quick one.
>>=20
>> I don't mind breaking compatibility on this issue, given that it never
>> worked properly anyway. Can you please file a ticket?
>>=20
>> D.
>>=20
>> On Wed, Jul 27, 2016 at 3:01 AM, Sergi Vladykin <sergi.vladykin@gmail.com=
>
>> wrote:
>>=20
>>> Nope. This will not work. Because take for example the following query:
>>>=20
>>> select my_enum_field from my_table where my_enum_field =3D 'BLA'
>>>=20
>>> Field well be evaluated only once here, but it must be a Sting and Enum
>> at
>>> the same time.
>>=20
>>=20
>>> Probably we could contribute to H2 `User defined value types` and handle=

>>> this stuff in our own Enum value types, which will support comparison
>> with
>>> String. But this requires bug H2 Modification and is a compatibility
>>> breaking change.
>>>=20
>>> Sergi
>>>=20
>>>=20
>>>=20
>>> 2016-07-27 9:23 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:
>>>=20
>>>> Hm... I would prefer to find a way to handle Enums automatically.
>>>>=20
>>>> In case if user expects a String, can we catch an exception and do
>>>> automatic conversion at that time? In this case, we could catch the
>>>> exception once and remember the decision. Will something like this
>> work?
>>>>=20
>>>> D.
>>>>=20
>>>> On Tue, Jul 26, 2016 at 1:49 AM, Sergi Vladykin <
>>> sergi.vladykin@gmail.com>
>>>> wrote:
>>>>=20
>>>>> GridQueryProcessor contains two types: BinaryProperty and
>>> ClassProperty.
>>>>> Indexing uses them for fields access. Probably we can change them, so
>>>> that
>>>>> they will always return String instead of Enum type but this
>>>>>=20
>>>>> 1. looks like a compatibility breaking change;
>>>>> 2. users doing queries like `select my_enum_field from my_table`
>>> probably
>>>>> still expect to get a Enum result but not a String.
>>>>>=20
>>>>> What do you think?
>>>>>=20
>>>>> Sergi
>>>>>=20
>>>>>=20
>>>>> 2016-07-26 3:17 GMT+03:00 Valentin Kulichenko <
>>>>> valentin.kulichenko@gmail.com
>>>>>> :
>>>>>=20
>>>>>> Sergi,
>>>>>>=20
>>>>>> Ideally, I would like this query to work:
>>>>>>=20
>>>>>> select * from MyTable where myEnumField =3D 'MY_ENUM_NAME'
>>>>>>=20
>>>>>> The problem is that the field value is not a string, it's a binary
>>>> object
>>>>>> with the enum value ordinal inside. We can add enum value names
>> into
>>>> the
>>>>>> metadata, so that we can always map the field value to its string
>>>>>> representation, but SQL engine will have to know how to use it. Is
>>> this
>>>>>> possible?
>>>>>>=20
>>>>>> -Val
>>>>>>=20
>>>>>> On Fri, Jul 22, 2016 at 10:25 PM, Sergi Vladykin <
>>>>> sergi.vladykin@gmail.com
>>>>>>> wrote:
>>>>>>=20
>>>>>>> I'm not sure what exactly you are going to patch in SQL engine. We
>>>> could
>>>>>>> and some SQL function like enum('MY_ENUM_NAME') but probably it
>> will
>>>> not
>>>>>>> work if we will not pass enum type there as well, so it have look
>>> like
>>>>>>> enum('com.mycompany.MyEnum', 'MY_ENUM_NAME') which is ugly.
>>>>>>>=20
>>>>>>> Sergi
>>>>>>>=20
>>>>>>> On 23 =C9=C0=CC=D1 2016 =C7., 0:43, Valentin Kulichenko <
>>>>>>> valentin.kulichenko@gmail.com
>>>>>>>> wrote:
>>>>>>>=20
>>>>>>>> Folks,
>>>>>>>>=20
>>>>>>>> I noticed that we currently have a very weird limitation for
>> enum
>>>>> fields
>>>>>>>> when running SQL queries. Basically, you can't use enum value
>>> names
>>>> as
>>>>>>> many
>>>>>>>> users would expect.
>>>>>>>>=20
>>>>>>>> Technically this happens because binary format stores only
>> ordinal
>>>> and
>>>>>>> the
>>>>>>>> only way to run such query is to do something like this:
>>>>>>>>=20
>>>>>>>> SqlFieldsQuery qry =3D new SqlFieldsQuery("select * from Table
>> where
>>>>>>>> enumField =3D ?");
>>>>>>>> qry.setArgs(MyEnum.ENUM_VALUE);
>>>>>>>> cache.query(qry);
>>>>>>>>=20
>>>>>>>> This means that this query can be executed only if:
>>>>>>>> - IgniteCache API is used. So it doesn't work in JDBC driver,
>>>>> Zeppelin,
>>>>>>>> etc.
>>>>>>>> - The client that executes the query has the enum class on
>>>> classpath.
>>>>>>>>=20
>>>>>>>> My first thought about fixing this is to somehow store value
>> names
>>>> in
>>>>>>>> binary metadata and patch the SQL engine so that it understands
>>> how
>>>> to
>>>>>>> use
>>>>>>>> this information.
>>>>>>>>=20
>>>>>>>> Thoughts?
>>>>>>>>=20
>>>>>>>> -Val
>>=20