MongoDBCollection¶
MongoDBCollection
is an example of a concrete
Collection
implementation and comes baked into
Carbon. Unlike Collection
, all handler
operations are implemented. You should only have to configure which operations
you want enabled along with some extra collection level and collection operation
level configuration.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | // pre-collections-concreteInstantiationHeader
var path = require('path')
var carbon = require('carbon-io')
var __ = carbon.fibers.__(module)
var _o = carbon.bond._o(module)
var o = carbon.atom.o(module)
__(function() {
module.exports = o.main({
_type: carbon.carbond.Service,
dbUri: "mongodb://localhost:27017/mydb",
// first definition is for presentation, second is for testsing
dbUri: _o('env:CARBONIO_TEST_DB_URI') || "mongodb://localhost:27017/mydb",
// pre-collections-concreteInstantiationFooter
endpoints: {
feedback: o({
_type: carbon.carbond.mongodb.MongoDBCollection,
enabled: {
find: true
}
})
}
})
})
// post-collections-concreteInstantiationFooter
|
MongoDBCollection Configuration¶
MongoDBCollection
extends
Collection
with the following configuration
properties:
dbName
- This is only necessary if the
Service
instance connects to multiple databases and should be a key indbUris
.collectionName
- This is the name of the MongoDB collection that the endpoint will operate on.
querySchema
- This is the schema used to validate the query spec for multiple operations (e.g.,
find
,update
, etc.). It defaults to{type: 'object'}
.updateSchema
- This is the schema used to validate the update spec passed to the
update
operation. It defaults to{type: 'object'}
.updateObjectSchema
- This is the schema used to validate the update spec passed to the
updateObject
operation. It defaults to{type: 'object'}
.