When using the .NET SDK client, if a “bucket” element is present in the configuration in the app.config, calling ICluster.OpenBucket() always tries to open a bucket called “default”. https://github.com/couchbase/couchbase-net-client/blob/master/Src/Couchbase/Cluster.cs#L108
It seems like if there is only one bucket element present in the configuration, that value should be considered and used first. Otherwise we are forced to hard code the name of the bucket in the source code, or we have to add our own logic to choose the first bucket in the configuration.
Our bucket names can vary between environments, so hard-coding is not really an option, so we have had to come up with another work around.
It would be nice if this could be addressed in the SDK. Is there a place to file issues? Didn’t see it on the Git repo.
Issues can be filed at issues.couchbase.com. Which version of the SDK are you using?
@matthew.groves or @jmorris or @MikeGoldsmith might have more recommendations for your need.
Unfortunately, I think that behavior would be difficult to change without breaking backwards compatibility.
However, I find that you can usually just have another piece of configuration in appSettings that defines which bucket name to use.
Additionally, to simplify it further I like using dependency injection to inject the buckets, so I only have to check the configuration value once when the dependency injection container is initializing.
I wrote a .Net Standard extension that does this specifically for Couchbase. It was designed for .Net Core, but should work just fine in .Net Desktop so long as you’re using Microsoft.Extensions.DependencyInjection.
This is by design. The way to keep everything config based is to use an appSettings variable to hold the bucket name or better yet a config section name: https://github.com/couchbase/couchbase-net-client/blob/master/Src/Couchbase.IntegrationTests/app.config#L16-L22
By changing the value of the app.config, you can easily swap between different configurations for your environments.
Hopefully this helps.
Wow, thank you all for the quick responses!
We ended up going the appSetting route, which works just fine.