You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,6 +15,7 @@ Express-Cassandra is an advanced Cassandra ORM for NodeJS. No more hassling with
15
15
* support for complex queries, streaming and token based pagination
16
16
* support for user defined types/functions/aggregates
17
17
* support for batching ORM operations for atomic updates
18
+
* support for before and after hook functions for save/update/delete
18
19
* builtin experimental support for automatic migrations
19
20
20
21
This module uses datastax [cassandra-driver](https://github.com/datastax/nodejs-driver) for node and some of the base orm features are wrapper over a highly modified version of [apollo-cassandra](https://github.com/3logic/apollo-cassandra) module. The modifications made to the orm library was necessary to support missing features in the orm, keep it updated with the latest cassandra releases and to make it compatible with the advanced requirements of this module.
When you perform a save/update/delete operation, a hook function helps you to tap into it in order to change data or perform other operations. Following are the available hook functions you can define in your schema:
*`before_save` if defined, will be automatically called each time before a save operation is performed. The `instance` will contain the model instance, so you could modify instance values or perform other things based on it. The `options` will contain the query options being passed to cassandra. You could also modify the options or do things based on it. The `next` is a callback function and after you're done, you must call it like `next()` to let the data saved in cassandra. Otherwise you may also send an error message like `next(err)` to halt the save operation. In this case the data will not be saved and the caller will receive the error message via callback.
159
+
160
+
* `after_save` if defined, will be automatically called each time after a save operation is successfully performed. The `instance` will contain the model instance, so you could get the instance values that were actually used and perform other things based on it. Note that if you performed any database functions then the output of those functions will not be available in the instance object. For example if you used the `$db_function: 'uuid()'` to generate your id field, then the actual saved value will not be available in the instance object. If you need to know what id was generated, then you need to use the utility function `models.uuid()` in javascript and send that value in the id field instead of using $db_function. The `options` will contain the final query options passed to cassandra. The `next` is a callback function and after you're done, you must call it like `next()` to let the caller recieve it's callback. Otherwise you may also send an error message like `next(err)` and in this case the caller will receive the error message via callback.
161
+
162
+
*`before_update` if defined, will be automatically called each time before an update operation is performed. The `queryObject` and the `updateValues` will contain the query and updated values part of the update operation as is, so you could modify them if required or perform other things based on them. The `options` will contain the query options being passed to cassandra. You could also modify the options or do things based on it. The `next` is a callback function and after you're done, you must call it like `next()` to let the data updated in cassandra. Otherwise you may also send an error message like `next(err)` to halt the update operation. In this case the data will not be updated and the caller will receive the error message via callback.
163
+
164
+
* `after_update` if defined, will be automatically called each time after an update operation is successfully performed. The `queryObject` and the `updateValues` will contain the query and updated values part of the update operation as is, so you could get the query and values that were actually used and perform other things based on them. Note that if you performed any database functions then the output of those functions will not be available in the updateValues object. For example if you used the `$db_function: 'now()'` to update your `updatedAt` field, then the actual updated value will not be available in the `updateValues` object. If you need to know the updated value of the `updatedAt` field, then you need to generate the current timestamp in javascript and send that value in the updatedAt field instead of using $db_function. The `options` will contain the final query options passed to cassandra. The `next` is a callback function and after you're done, you must call it like `next()` to let the caller recieve it's callback. Otherwise you may also send an error message like `next(err)` and in this case the caller will receive the error message via callback.
165
+
166
+
*`before_delete` if defined, will be automatically called each time before a delete operation is performed. The `queryObject` will contain the query part of the delete operation as is, so you could modify them if required or perform other things based on them. The `options` will contain the query options being passed to cassandra. You could also modify the options or do things based on it. The `next` is a callback function and after you're done, you must call it like `next()` to let the data deleted in cassandra. Otherwise you may also send an error message like `next(err)` to halt the delete operation. In this case the data will not be deleted and the caller will receive the error message via callback.
167
+
168
+
*`after_delete` if defined, will be automatically called each time after a delete operation is successfully performed. The `queryObject` will contain the query part of the delete operation as is, so you could get the query that was actually used and perform other things based on it. The `options` will contain the final query options passed to cassandra. The `next` is a callback function and after you're done, you must call it like `next()` to let the caller recieve it's callback. Otherwise you may also send an error message like `next(err)` and in this case the caller will receive the error message via callback.
0 commit comments