Nope. This will not work. Because take for example the following query:
select my_enum_field from my_table where my_enum_field = 'BLA'
Field well be evaluated only once here, but it must be a Sting and Enum at
the same time.
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.
Sergi
2016-07-27 9:23 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
> Hm... I would prefer to find a way to handle Enums automatically.
>
> 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?
>
> D.
>
> On Tue, Jul 26, 2016 at 1:49 AM, Sergi Vladykin <sergi.vlady...@gmail.com>
> wrote:
>
> > 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
> >
> > 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.
> >
> > What do you think?
> >
> > Sergi
> >
> >
> > 2016-07-26 3:17 GMT+03:00 Valentin Kulichenko <
> > valentin.kuliche...@gmail.com
> > >:
> >
> > > Sergi,
> > >
> > > Ideally, I would like this query to work:
> > >
> > > select * from MyTable where myEnumField = 'MY_ENUM_NAME'
> > >
> > > 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?
> > >
> > > -Val
> > >
> > > On Fri, Jul 22, 2016 at 10:25 PM, Sergi Vladykin <
> > sergi.vlady...@gmail.com
> > > > wrote:
> > >
> > >> 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.
> > >>
> > >> Sergi
> > >>
> > >> On 23 июля 2016 г., 0:43, Valentin Kulichenko <
> > >> valentin.kuliche...@gmail.com
> > >> > wrote:
> > >>
> > >> > Folks,
> > >> >
> > >> > 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.
> > >> >
> > >> > Technically this happens because binary format stores only ordinal
> and
> > >> the
> > >> > only way to run such query is to do something like this:
> > >> >
> > >> > SqlFieldsQuery qry = new SqlFieldsQuery("select * from Table where
> > >> > enumField = ?");
> > >> > qry.setArgs(MyEnum.ENUM_VALUE);
> > >> > cache.query(qry);
> > >> >
> > >> > 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.
> > >> >
> > >> > 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.
> > >> >
> > >> > Thoughts?
> > >> >
> > >> > -Val
> > >> >
> > >>
> > >
> > >
> >
>
