You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by GitBox <gi...@apache.org> on 2019/08/08 06:45:32 UTC

[GitHub] [incubator-shardingsphere] rimal edited a comment on issue #2826: Ability to define behaviour when sharding column is not present in the SQL

rimal edited a comment on issue #2826: Ability to define behaviour when sharding column is not present in the SQL
URL: https://github.com/apache/incubator-shardingsphere/issues/2826#issuecomment-519388914
 
 
   @terrymanu Thanks for your reply.
   
   Honestly, I see Sharding JDBC as a layer over my datasource. I believe that since Sharding JDBC is actually a part of the application and not something in between the application and the database (like ProxySQL), Sharding JDBC is much more powerful as it can let me shard via an application logic as well and not only on basis of the SQL.
   
   Also, I ll try to shed some light on my use case:
   
   - I have a multi-tenant application and we are sharding by tenant identifier. 
   - Almost all requests served by the application are within the scope of the tenant.
   - Not all queries have the sharding column  (in my case, the tenant identifier). 
   - If the query has sharding column, i will want to decide the target name as per that.
   - Otherwise, I will fetch tenant information from the current request being served by the application, and then decide target name from that 
   
   I have a patch in my mind which should resolve this use case. If it will be ok, i can submit that as a pull request. 
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services