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
Serviceinstance 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
updateoperation. It defaults to{type: 'object'}.updateObjectSchema- This is the schema used to validate the update spec passed to the
updateObjectoperation. It defaults to{type: 'object'}.