Dima,
"cache-less" means that SQL executed directly on SQL engine.
In previous version of Ignite we execute queries via cache:
ignite.cache("Some cache").sqlFieldsQuery("select ... from ..")
In current Ignite we can execute query directly without using cache as
"gateway".
And if we execute query directly, metrics not update.
On Fri, Aug 17, 2018 at 4:21 AM Dmitriy Setrakyan <dsetrak...@apache.org>
wrote:
> Evgeny, what is a "cache-less" SQL query?
>
> D.
>
> On Thu, Aug 16, 2018 at 6:36 AM, Evgenii Zhuravlev <
> e.zhuravlev...@gmail.com
> > wrote:
>
> > Hi Igniters,
> >
> > I've started to work on adding QueryDetailMetrics for cache-less SQL
> > queries(issue https://issues.apache.org/jira/browse/IGNITE-6677) and
> found
> > that it's required to change API. I don't think that adding methods like
> > queryDetailMetrics, resetQueryDetailMetrics, as in IgniteCache to Ignite
> > class is a good idea. So, I see 2 possible solutions here:
> >
> > 1. Create IgniteMetrics(ignite.metrics()) and move metrics from
> > Ignite(like dataRegionMetrics and dataStorageMetrics) and add a new
> > metric "queryDetailMetrics" to it. Of course, old methods will be
> > deprecated.
> >
> > 2. Finally create Ignite.sql() API, which was already discussed here:
> > http://apache-ignite-developers.2346864.n4.nabble.
> > com/Rethink-native-SQL-API-in-Apache-Ignite-2-0-td14335.html
> > and place "queryDetailMetrics" metric there. Here is the ticket for this
> > change: https://issues.apache.org/jira/browse/IGNITE-4701
> >
> > Personally, I think that the second solution looks better in this case,
> > however, moving dataRegionMetrics and dataStorageMetrics to
> > ignite.matrics() is still a good idea - IMO, Ignite class is not the
> right
> > place for them - we shouldn't change our main API class so often.
> >
> > What do you think?
> >
> > Thank you,
> > Evgenii
> >
>
> --
> Alexey Kuznetsov
>
>
