I do support Sergi’s proposal. We already set aliases (setAliases(…)) and indexes (setIndexes(…)) in a similar way.
— Denis > On Nov 7, 2016, at 12:33 AM, Sergi Vladykin <sergi.vlady...@gmail.com> wrote: > > I don't think per field configuration makes a big sense. I would just add > another property to QueryEntity like setCaseInsensitiveFields(Set<String> > fields). > > Sergi > > > > 2016-11-07 9:09 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > >> Hi Amir, >> >> Having POJO class QueryField looks like a good idea to me. Because we will >> be able to encapsulate more field information into it over time. E.g. we >> can add "keyField" flag for DML there. >> >> I would even think about removing map from method signature in favor of >> simple list/array: >> >> void setFields(QueryField...); >> >> Vladimir. >> >> 07 нояб. 2016 г. 7:32 пользователь "Amir Akhmedov" < >> amir.akhme...@gmail.com> >> написал: >> >> Hi Igniters, >> >> I was looking into ticket IGNITE-3999 and I have a concern on this, can you >> please advise what will be the correct way to solve it. As of today, SQL >> fields are defined as setFields(LinkedHashMap<String, String> fields), >> with >> introduction of case insensitive property need to create a new POJO >> e.g. QueryField(String >> type, boolean caseInsensitive). So, to keep backward compatibility we can >> introduce a new method e.g. setQueryFields(LinkedHashMap<String, >> QueryField> fields), in my opinion it looks like counter-intuitive with >> existing setFields method. Another possible way, this change can be done >> with changing the generic type of setFields (which will not be backward >> compatible) and released in Ignite 2.0. >> Please advise on this, or maybe you have an alternative solutions? >> >> -- >> Sincerely Yours Amir Akhmedov >>
