Hi liang, I am very glad to know the direction of future development for shardingsphere.
the interface about database scaling should be define or not? I am working for sharding-scaling project, I think the interface definition about database scaling is good for this project. > 在 2019年9月28日，下午9:34，Juan Pan <[email protected]> 写道： > > Making feature independent and use them in mixed mood? > It sounds great, but challenging. It will take a lot of time to do, i think... > > > > > Juan Pan > > > [email protected] > Juan Pan(Trista), Apache ShardingSphere > On 09/28/2019 18:44, Sheng Wu wrote: > Does making this change in 5 make more sense? > And we provide v4 unchanged for user convenient. > > Sheng > > [email protected] <[email protected]>于2019年9月28日 周六下午6:15写道： > >> The scope of ShardingSphere keep expanding. Sharding is not the unique and >> core feature for ShardingSphere anymore. >> >> So we plan to create pluggable infrastructure for database proxy and JDBC >> driver which to let users run it without any additional function, just >> transparent transmission. ShardingSphere can add more features into `EMPTY` >> infrastructure, such as sharding, master-slave, encrypt, >> distributed-transaction, orchestration and so on. >> >> The API may look like: ShardingDataSource, MasterSlaveDataSource, >> EncryDataSource, DistributedTransactionDataSource and >> OrchestrationDataSource, the yaml and other configuration methods should >> change to this way too. >> >> Every features are independent and can be work together which using >> composited and append-able way. We can provide SSDataSourceFacade to manage >> how to use them together. >> >> This is one of the reason to why we do not release for 4.0.0 stable version >> soon, we want more discuss to make decision to change API before 4.0.0 >> stable version release. >> >> Any suggestions? >> >> ------------------ >> >> Liang Zhang (John) >> Apache ShardingSphere & Dubbo >> > -- > Sheng Wu > SkyWalking, Shardingsphere and Zipkin
