ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: SqlFields query result does not expose fields metadata.
Date Thu, 18 May 2017 12:36:33 GMT
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