It should not require any internals movement, it must be an easy fix. Sergi
2017-05-18 15:36 GMT+03:00 Vladimir Ozerov <[email protected]>: > With all the changes to internals we made, new API can be created very > quickly somewhere around AI 2.2 or AI 2.3. Currently the whole API is > located in the wrong place, as it is bounded to cache. So the more we add > now, the more we will deprecate in several months. Remember, that this > feature will require not only new interface, but moving existing *internal* > metadata classes to public space. These classes were never designed to be > exposed to users in the first place. > > This is why I am strongly against this change at the moment. No need to > make already outdated and complex API even more complex without strong > demand from users. > > On Thu, May 18, 2017 at 3:29 PM, Pavel Tupitsyn <[email protected]> > wrote: > > > I agree that this change makes sense. > > With complex queries it may be non-trivial to get the right column by > index > > from results. > > With metadata user no longer needs to care about result column order, and > > refactorings are easier. > > > > Pavel > > > > On Thu, May 18, 2017 at 2:36 PM, Sergi Vladykin < > [email protected]> > > wrote: > > > > > I believe we will not see this new SQL API soon. It is not even in > design > > > stage. > > > > > > The change proposed by Andrey is very simple and our users will benefit > > > from it right away. > > > > > > I see no reasons to disallow this change. > > > > > > Sergi > > > > > > 2017-05-18 12:35 GMT+03:00 Vladimir Ozerov <[email protected]>: > > > > > > > Result set metadata is exposed to JDBC and ODBC drivers because it is > > > > required by JDBC specification and lot's external applications use > it. > > I > > > do > > > > not see big demand for this feature in native SQL, where user > normally > > > > knows the model. Another point is that with changes introduced in > > recent > > > > versions (DML, DDL, shared schemas), we need brand new native SQL > API, > > as > > > > current IgniteCache.query() cannot conveniently reflect current and > > > planned > > > > Ignite capabilities. > > > > > > > > For this reason I do not think we should do proposed change. Instead, > > we > > > > should add metadata retrieval to new SQL API. > > > > > > > > Vladimir. > > > > > > > > On Thu, May 18, 2017 at 12:19 PM, Andrey Mashenkov < > > > > [email protected]> wrote: > > > > > > > > > Hi Igniters, > > > > > > > > > > When user run Sql query via JDBC, he can get fields metadata (field > > > > names, > > > > > its types and etc.) from ResultSet. > > > > > With IgniteCache.query method he gets some QueryCursor > > implementation, > > > > but > > > > > QueryCursor interface doesn't have any methods for this. > > > > > > > > > > For now, the only way to get metadata is try to cast result to > > internal > > > > > QueryCursorImpl class. > > > > > > > > > > I think it should break nothing if we overload > > > > > IgniteCache.query(SqlFieldsQuery q) return type to a new > > > > FieldsQueryCursor > > > > > interface. > > > > > FieldsQueryCursor will be inherits from QueryCursor and provide > > > > additional > > > > > methods, > > > > > > > > > > Thoughts? > > > > > > > > > > -- > > > > > Best regards, > > > > > Andrey V. Mashenkov > > > > > > > > > > > > > > >
