Details
Description
When a bucket is deleted, any full text indexes that had that bucket as a data source should also be deleted. Put another way, "cascading delete of indexes in cbgt when data source is deleted".
One way to implement this is that cbgt-ctl (the renamed "MCP") can monitor ns-server for bucket changes. A client can make a "bucket streaming" or "bs" request to ns-server to ask for the configuration changes for a specific bucket. Via...
http://localhost:8091/pools/default/bs/BUCKET_NAME
For example, if you do...
curl http://localhost:8091/pools/default/bs/beer-sample
...you'll see that the curl stays open as the HTTP response stream remains open. Occasionally, ns-server will write changes to the HTTP response stream. For example, if you try to change the RAM quota of the beer-sample bucket, then you should see more output of the curl command.
Then, if you next delete the beer-sample bucket, you'll finally see the curl command exit, as the HTTP response stream is finally closed by ns-server.
That's the event that I think should be detected, and the (imaginary) implementation can go through all the indexes in cbgt and compare the SourceType, SourceName, SourceUUID's to see if the actual couchbase data source buckets (with matching UUID's) are deleted. And, then delete the corresponding indexes. So, it's eventual deletion.
If the user concurrently races to recreate a bucket of the same name as a just-deleted bucket, the newly recreated bucket should have a different bucket UUID, which the (imaginary) implementation can detect by comparing to the SourceUUID value for an index.
I think this (imaginary) implementation work should probably be done in the github.com/couchbase/cbgt/cmd/cbgt-ctl files, as it should be part of cbgt-ctl.