Thanks. We are not in hurry. When you are ready, I will invest and dive in how to make this integration works.
Data access, w/ all SQL, NO-SQL DB and cache, are highly valuable to end users. Sheng Wu Apache Skywalking, ShardingSphere, Zipkin > 在 2019年7月15日，下午3:34，[email protected] 写道： > > 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 >>>> >>>> >>>> >>>> >> >>
