The MongoBundle offers integration with MongoDB database by allowing you to hook into events, giving ability to work with model classes and add behaviors (such as timestampable, blameable). As well it is integrated with
@kaviar/nova package which allows extremely rapid queries for relational data.
A collection is in fact a service. Thus making it accessible via the
container. We define our collections as extensions of
Collection in which we can customise things such as:
As with everything in Kaviar's world, you get the instance via the container, for that you'd have to work within your application bundle.
You have access to directly perform the more popular mutation operations:
What's nice about this is that you can listen to all events for the operations you do strictly on the collection. If you do
usersCollection.collection.insertMany the events won't be dispatched, but if you do
usersCollection.insertMany it will.
Available events that can be imported from the package:
They are very explicit and typed with what they contain, a sample usage would be:
Events should be attached in the
prepare() phase of your bundle. The common strategy is by warming up a Listener, as described in the core.
Events also receive a
context variable. Another difference from classic MongoDB node collection operations is that we allow a
context variable inside it that can be anything. That variable reaches the event listeners. It will be useful if we want to pass things such as an
userId if we want some blameable behavior. You will understand more in the Behaviors section.
If you want to perform certain actions for elements once they have been updated or removed (events:
AfterRemoveEvent) the solution is to get the filter and extract the
_id from there.
For fetching we use Nova. And the concept is simple:
To integrate with Nova, you can do it via the following static variables
Now you can query freely:
If you are looking to write a Nova Query in your GraphQL resolvers you can do:
If you want the query to return a single element, a short-hand function is
The nature of the behavior is simple, it is a
function that receives the
collection object when the collection initialises. And you can listen to events on the collection and make it behave.
Now, you may have behaviors that require you to provide a context to the operations. Not doing so, they will be allowed to throw exceptions and block your execution. For example if you have blameable behavior, and you do not have a context with
userId being either
null either a value, an exception will be thrown.
If you need to access the container, for example, you want to log the events into an external service you can access the container via
behavior is a function that take in the collection's instance and performs manipulation on it, b
y either hooking to events or overriding/extending its methods.
Each collection has it's own event manager in which it dispatches events. When adding behaviors it would be great to use the
If we need to have logicfull models then it's easy. We are leveraging the power of
class-transformer to do exactly that.
Now, if you want to query only for fullName, because that's what you care about, you'll have to use expanders. Expanders are a way to say "I want to compute this value, not Nova, so when I request this field, I need you to actually fetch me these other fields"
However, you can also leverage Nova to do this computing for you like this:
If you want to have nested models that reference other collections, it's easy:
Now doing the query:
If you want to ensure that all your updates are run and if an exception occurs you would like to rollback. For example, you have event listeners that you never want to fail, or you do multiple operations in which you must ensure that all run and if something bad happens you can revert.
The beautiful thing is that any kind of exception will result in transaction revertion. If you want to have event listeners that don't fail transactions, you simply wrap them in such a way that their promises resolve.
Migrations allow you to version and easily add new changes to database while staying safe. Migrations are added in the
prepare() phase of your bundles.
By default migrations are run by default to latest version right after
MongoBundle gets initialised.
The way we handle migrations is that we store in
migrations collection a status object containing: