Camel MongoDB component
Available as of Camel 2.10
According to Wikipedia: "NoSQL is a movement promoting a loosely defined class of non-relational data stores that break with a long history of relational databases and ACID guarantees." NoSQL solutions have grown in popularity in the last few years, and major extremely-used sites and services such as Facebook, LinkedIn, Twitter, etc. are known to use them extensively to achieve scalability and agility.
Basically, NoSQL solutions differ from traditional RDBMS (Relational Database Management Systems) in that they don't use SQL as their query language and generally don't offer ACID-like transactional behaviour nor relational data. Instead, they are designed around the concept of flexible data structures and schemas (meaning that the traditional concept of a database table with a fixed schema is dropped), extreme scalability on commodity hardware and blazing-fast processing.
MongoDB is a very popular NoSQL solution and the camel-mongodb component integrates Camel with MongoDB allowing you to interact with MongoDB collections both as a producer (performing operations on the collection) and as a consumer (consuming documents from a MongoDB collection).
MongoDB revolves around the concepts of documents (not as is office documents, but rather hierarchical data defined in JSON/BSON) and collections. This component page will assume you are familiar with them. Otherwise, visit http://www.mongodb.org/.
URI format
mongodb:connectionBean?database=databaseName&collection=collectionName&operation=operationName[&moreOptions...]
Endpoint options
MongoDB endpoints support the following options, depending on whether they are acting like a Producer or as a Consumer (options vary based on the consumer type too).
Name |
Default Value |
Description |
Producer |
Tailable Cursor Consumer |
---|---|---|---|---|
|
none |
Required. The name of the database to which this endpoint will be bound. All operations will be executed against this database unless dynamicity is enabled and the |
|
|
|
none |
Required. The name of the collection (within the specified database) to which this endpoint will be bound. All operations will be executed against this database unless dynamicity is enabled and the |
|
|
|
none |
Required for producers. The id of the operation this endpoint will execute. Pick from the following:
|
|
|
|
true |
Determines whether the collection will be automatically created in the MongoDB database during endpoint initialisation if it doesn't exist already. If this option is |
|
|
|
false (behaviour may be inherited from connections WriteConcern) |
Instructs the MongoDB Java driver to invoke |
|
|
|
none (driver's default) |
Set a |
|
|
|
none |
Sets a custom |
|
|
|
none |
Sets a |
|
|
|
false |
If set to true, the endpoint will inspect the |
|
|
|
false |
Enables or disables persistent tail tracking for Tailable Cursor consumers. See below for more information. |
|
|
|
none |
Required if persistent tail tracking is enabled. The id of this persistent tail tracker, to separate its records from the rest on the tail-tracking collection. |
|
|
|
none |
Required if persistent tail tracking is enabled. Correlation field in the incoming record which is of increasing nature and will be used to position the tailing cursor every time it is generated. The cursor will be (re)created with a query of type: tailTrackIncreasingField > lastValue (where lastValue is possibly recovered from persistent tail tracking). Can be of type Integer, Date, String, etc. NOTE: No support for dot notation at the current time, so the field should be at the top level of the document. |
|
|
|
1000ms |
Establishes how long the endpoint will wait to regenerate the cursor after it has been killed by the MongoDB server (normal behaviour). |
|
|
|
same as endpoint's |
Database on which the persistent tail tracker will store its runtime information. |
|
|
|
camelTailTracking |
Collection on which the persistent tail tracker will store its runtime information. |
|
|
|
lastTrackingValue |
Field in which the persistent tail tracker will store the last tracked value. |
|
|
MongoDB operations
Query operations
findById
This operation retrieves only one element from the collection whose _id field matches the content of the IN message body. The incoming object can be anything that has an equivalent to a BSON type. See http://bsonspec.org/#/specification and http://www.mongodb.org/display/DOCS/Java+Types.
from("direct:findById") .to("mongodb:myDb?database=flights&collection=tickets&operation&operation=findById") .to("mock:resultFindById");
Supports fields filter
findOneByQuery
Use this operation to retrieve just one element from the collection that matches a MongoDB query. The query object is extracted from the IN message body, i.e. it should be of type DBObject
or convertible to DBObject
. See [Type conversions].
from("direct:findOneByQuery") .to("mongodb:myDb?database=flights&collection=tickets&operation&operation=findOneByQuery") .to("mock:resultFindOneByQuery");
Supports fields filter
findAll
The findAll
operation returns all documents matching a query, or none at all, in which case all documents contained in the collection are returned.
from("direct:findAll") .to("mongodb:myDb?database=flights&collection=tickets&operation=findAll") .to("mock:resultFindAll");
Supports fields filter
Paging and efficient retrieval is supported via the following headers:
Header key |
Quick constant |
Description (extracted from MongoDB API doc) |
Expected type |
---|---|---|---|
|
MongoDbConstants.NUM_TO_SKIP |
Discards a given number of elements at the beginning of the cursor. |
int/Integer |
|
MongoDbConstants.LIMIT |
Limits the number of elements returned. |
int/Integer |
|
MongoDbConstants.BATCH_SIZE |
Limits the number of elements returned in one batch. A cursor typically fetches a batch of result objects and store them locally. If batchSize is positive, it represents the size of each batch of objects retrieved. It can be adjusted to optimize performance and limit data transfer. If batchSize is negative, it will limit of number objects returned, that fit within the max batch size limit (usually 4MB), and cursor will be closed. For example if batchSize is -10, then the server will return a maximum of 10 documents and as many as can fit in 4MB, then close the cursor. Note that this feature is different from limit() in that documents must fit within a maximum size, and it removes the need to send a request to close the cursor server-side. The batch size can be changed even after a cursor is iterated, in which case the setting will apply on the next batch retrieval. |
int/Integer |
Additionally, you can set a sortBy criteria by putting the relevant DBObject
describing your sorting in the CamelMongoDbSortBy
header, quick constant: MongoDbConstants.SORT_BY
.
Supports fields filter
Specifying a field filter
Query operations will, by default, return matching objects in their entirety. If your documents are large and you are only interested in retrieving a subset of their fields, you can specify a field filter in all query operations, simply by setting the relevant DBObject
(or type convertible to DBObject
, such as a JSON String, Map, etc.) on the CamelMongoDbFieldsFilter
header, constant shortcut: MongoDbConstants.FIELDS_FILTER
.
An example that uses MongoDB's BasicDBObjectBuilder to simplify the creation of DBObjects:
DBObject fieldFilter = BasicDBObjectBuilder.start().add("_id", 0).add("fixedField", 0).get(); Object result = template.requestBodyAndHeader("direct:findAll", (Object) null, MongoDbConstants.FIELDS_FILTER, fieldFilter);