The basic information can be got from SQLStatement API which outside ShardingSphere. But I think we still has more jobs to do if SkyWalking want use it, such as design a friendly parse API.
I hope we can finish the public parse API at next release(4.0.0-RC3), and wish SkyWalking can use it in future. ------------------ Liang Zhang (John) Apache ShardingSphere & Dubbo Sheng Wu <[email protected]> 于2019年7月15日周一 下午2:00写道： > > > > 在 2019年7月15日，下午12:59，[email protected] 写道： > > > > The enhancement of new SQL parser is use ANTLR to instead of self-dev. It > > is more easy to extends other database dialect than before. > > The parse engine is a internal API for ShardingSphere for now, the API is > > not pubic for now. We just plan to open the public parse API on next > > release. > > For now, the parse engine's API is not very stable, maybe need little > > change in future. > > > > If SkyWalking want try to use it, you may start from > > `org.apache.shardingsphere.core.parse.sql.statement.SQLStatement`, it is > > the parse result of SQL. But the entry of SQLParseEngine is for Sharding > or > > Encrypt, it is not friendly enough for 3rd party users now. > > I think that makes SkyWalking can’t use it. As a high performance agent, > we can’t pay the price to run analysis inside application codes, > We are trying to do that in backend, it means, we only get the SQL > statement string, with parameter(maybe, optional today) > > > > > > Let's talk about the 3 features SkyWalking want: > > > >> 1. Table access frequency. > > > > May use `SQLStatement.getTables()` to get table names and calculate what > > you want. > > > >> 2. Write-Read payload > > > > SQLStatement has lots of subclass, user may use instanceof to > > `SelectStatement` or other `DMLStatement` to get SQL type. I prefer to > add > > a new method `getSQLType()` to expose SQL type in future. > > > >> 3. Typical SQL statement usage, rather than PrepareStatement used. > > > > This is not SQL parser's scope, maybe you should do it in JDBC layer. in > > SQL parser, user only can do is calling > `SQLStatement.getParametersCount()` > > to know the count of parameter markers of the SQL. > > All these are requirements to SkyWalking, not to ShardingSphere core. > We just want to leverage ShardingSphere core to get basic information, > such as statement type, read or write, major target table of read or write. > All these may be possible to get from your SQL parser engine, if you try > to make it more friendly to observability(no must be SkyWalking). > > > Anyway, thanks for the feedback. I will keep watching. > > Sheng Wu > Apache Skywalking, ShardingSphere, Zipkin > > > > > > > > > ------------------ > > > > Liang Zhang (John) > > Apache ShardingSphere & Dubbo > > > > > > Sheng Wu <[email protected]> 于2019年7月15日周一 上午11:54写道： > > > >> Hi > >> > >> I noticed this in next release changelog > >>> The parse engine upgrade from the 2nd generation to 3rd. > >> > >> Where could I find the definition, API and feature of your new parser > >> engine? Is it more friendly to be used as a package out of > ShardingSphere > >> core? > >> I invented the parser core 5 months ago, it seems very internal APIs. > But > >> I want to use it in Apache SkyWalking to SQL analysis, which could give > me > >> 1. Table access frequency. > >> 2. Write-Read payload > >> 3. Typical SQL statement usage, rather than PrepareStatement used. > >> > >> Maybe more. SkyWalking wouldn’t build any SQL parser, because it is > waste > >> of time to redo such huge workloads. > >> > >> Hope anyone could give me some feedback or is this possible on the > >> engineer roadmap? > >> > >> > >> Sheng Wu > >> Apache Skywalking, ShardingSphere, Zipkin > >> > >> > >> > >> > >
