ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergi Vladykin <sergi.vlady...@gmail.com>
Subject Re: SqlFields query result does not expose fields metadata.
Date Thu, 18 May 2017 16:39:58 GMT
It should not require any internals movement, it must be an easy fix.

Sergi

2017-05-18 15:36 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com>:

> 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 <ptupitsyn@apache.org>
> 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 <
> sergi.vladykin@gmail.com>
> > 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 <vozerov@gridgain.com>:
> > >
> > > > 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 <
> > > > andrey.mashenkov@gmail.com> 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
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message