cqlsh uses the Python driver, I don't see how there would be any way to differentiate where the request came from unless you stuck an extra field in the table that you always write when you're not in cqlsh, or you modified cqlsh to include that field whenever it did an insert.
Checking iTrigger source, all you get is a reference to the ColumnFamily and some metadata. At a glance of trunk, it doesn't look like you get the user that initiated the query. To be honest, I wouldn't do any of this, it feels like it's going to become an error prone mess. Your best bet is to layer something on top of the driver yourself. The cleanest way I think think of, long term, is to submit a JIRA / patch to enable some class loading & listener hooks in cqlsh itself. Without a patch and a really good use case I don't know who would want to maintain that though, as it would lock the team into using Python for cqlsh. Jon On Fri, Nov 11, 2016 at 9:52 AM sat <sathish.al...@gmail.com> wrote: > Hi, > > We are planning to use ITrigger to notify changes, when we execute scripts > or run commands in cqlsh prompt. If the operation is performed through our > application CRUD API, we are planning to handle notification in our CRUD > API itself, however if user performs some operation(like write operation in > cqlsh prompt) we want to handle those changes and update modules that are > listening to those changes. > > Could you please let us know whether it is possible to differentiate > updates done through cqlsh prompt and through application. > > We also thought about creating multiple users in cassandra and using > different user for cqlsh and for the application. If we go with this > approach, do we get the user who modified the table in ITrigger > implementation (ie., augment method) > > > Basically we are trying to limit/restrict usage of ITrigger just for cqlsh > prompt as it is little complex and risky (came to know it will impact > cassandra running in that node). > > Thanks and Regards > A.SathishKumar > >
