Create Scopes & Collections - ensureCollections
See original GitHub issueIn the current implementation, the ottoman.start()
method is used to bootstrap Ottoman.
- ottoman.start() method accepts configuration
useCollections()
this should be removed.
Create / modify methods
ensureIndexes - creates indexes depending on the scenario. ensureCollections - creates scopes and collections depending on the scenario
start - calls ensureCollections()
first and then ensureIndexes()
.
ensureCollections()
- Below are different scenarios
- Scenario 1: Scopes & Collections UNSUPPORTED, If a user configures
scopeName
andcollectionName
thenensureCollections()
should attempt to create the scope and collection, the attempt to create a scope and collection should fail because this feature is not supported by Couchbase Server. The code should rely on the exception thrown by the underlying SDK (probably unsupported exception) and then return a proper error message to the user: This version of Couchbase Server does not support scopes and collections.
Note: There is no mechanism currently that will let you know if the Cluster you are working with supports Scopes & Collections or that will give you the server version back, you will have to rely on the underlying SDK error message for this. At the time of creating this issue, an open issue in Node.js SDK exists that takes care of throwing the right exception back. Until this is resolved using a global configuration in your tests assuming Supported vs Unsupported Platform
-
Scenario 2: Scopes & Collections UNSUPPORTED, If the user DOES NOT configure a
scopeName
andcollectionName
thenensureCollections()
should NOT attempt to create thedefault
scope anddefault
collection. -
Scenario 3: Scopes & Collections SUPPORTED, If user configures
scopeName
andcollectionName
thenensureCollections()
should attempt to create the scope and collection. -
Scenario 4: Scopes & Collections SUPPORTED, If the user DOES NOT configure a
scopeName
andcollectionName
thenensureCollections()
should NOT attempt to createdefault
scope anddefault
collection, because _default a scope cannot be dropped. A _default collection can be dropped but it cannot be recreated (so no point in attempting to recreate)
as a general guideline
ensureCollections should be called before ensureIndexes. Global Scope and Collection configuration takes precedence over Model Level Scope and Collection
The repository below exhibits in general test cases with a certain combination of global and Model Configuration for 7.0 Server and for Legacy (Unsupported Database)
Note : the above repository doesn’t necessarily give all permutations and combinations of global vs model level configuration that should follow the general guidelines as discussed above. However, the repository gives you examples of how to do global configuration and what to expect as an outcome.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (4 by maintainers)
Top GitHub Comments
The default should be ‘_default’ rather than the model name. There is another global-level config option which we will likely want in the future which provides the behaviour you described, but for compatibility reasons it cannot be the default.
Even though the issue on the customer side is still open, the latest comments indicates that these issues can be closed. We may open a new issue as needed