I must admit being a newbie for Couchbase. While trying to use where predicates with query APIs, an exception is thrown indicating no Index found for the KeySpace… In this regard, I have a question -
How does it work to know the model schema at persistence layer (in order to create Index on filterable attributes) while the schema belongs to the business logic? Wouldn’t the persistence require a change everytime there is a change in the business entity or a new entity is introduced?
Do you have a primary index defined? Something like:
CREATE PRIMARY INDEX ON `default`;
Where default is the bucket you are querying. If not use the Query Editor in the Management Console to do this.
-Jeff
Yes, I did create the primary index which actually fixed the exception.
I am however given to understand that having only primary index is not optimized and is not recommended in production use.
My usecase in a brief - we do not expect to store a high volume of data (around 1 GB at any given point) however have requirements to perform moderately frequent and flexible query operations (using Linq2Couchbase) based on different attributes within the document.
I’m not 100% sure what the goal of your question is, it’s a bit broad. However, I feel like you might also be asking about how to manage indexes from development through to production deployments. Just in case, I’ll answer that question for you.
At CenterEdge, we use an open source utility I developed called couchbase-index-manager for years. This utility manages indexes through declarative state files. It analyzes your cluster’s state, generates a plan for index changes to reach the desired state defined in the files, and executes that plan. It’s also idempotent, it can be safely run with the current state and it will just do nothing. The state files are YAML based and designed to be committed to source control, giving you history, the ability to revert, etc. It is available on NPM and Docker Hub.
The next part is how to manage indexes during the local development experience. If your indexes locally don’t match what’s in production you can have unexpected results upon deployment. For managing this, I recommend using the CouchbaseFakeIt docker image. It allows you to easily spin up Couchbase, usually using a docker-compose file, preconfigured with indexes, views, fake data, users, and more.
Internally, it uses couchbase-index-manager for the purpose of index management. So your index definition files are mostly identical. You may simply have some different override files to manage differences in replica counts.
I hope this helps.
Thanks @btburnett3 for the recommendations. It did help me in right direction. 