Comments (9)
Hey @jamesholcomb i know some time has passed by I finally made the time to dig through all open issues. Hopefully you still somewhat know what this was about.
In my understanding lean()
and rawResult: true
is mostly used for performance or raw access. In both cases a patch history does not need to be kept. Is that right or am I wrong here?
A simple fix would then be to state it in the README and disable the plugin hooks if lean
or rawResult
is detected.
from mongoose-patch-history.
Hey @jamesholcomb,
thanks for letting us know!
I think we can support this. I'll have a deeper look over the weekend.
from mongoose-patch-history.
Additionally, specifying rawResult: true
does not work either. It's related to this issue since the virtual functions (e.g. data()
) are not provided when the raw result from the driver is returned in the schema.post
function.
A simple test already exists for rawResult
, but it does not actually assert the patch history.
from mongoose-patch-history.
I ended up refactoring my code by removing lean
and rawResult
from all write ops that use patch history.
Would it be more useful to throw an error if the lib detects either of those options?
from mongoose-patch-history.
Thanks for answering!
Then I would propose throwing an error and providing a config option to disable error throwing?
from mongoose-patch-history.
Perhaps you could expand on the behavior of 'disable the plugin hooks'
from mongoose-patch-history.
Under plugin hooks
i understand the functionality of the plugin. So if thelean
or rawResult
option is detected we can disable the plugin functionality (configurable). So either throw error or the users "knows what he is doing" and we disable the error throwing.
from mongoose-patch-history.
From an end user perspective, it is hard to imagine a scenario where you would explicitly configure a collection for patch history but disable the plugin if your db writes utilize those mongoose options. Especially lean
, as it it used for performance optimization. But it's hard to predict every use case, so I understand the point of view.
If you go with a "throw on error" style option, it would be prudent to enable by default.
from mongoose-patch-history.
But it's hard to predict every use case, so I understand the point of view.
Isn't lean
basically circumventing mongoose? It is used to gather raw results, it can be used to write if I'm not mistaken here.
So the following update operation (if any) will run through mongoose and should be supported by the patch-history-plugin again.
Just some quick thoughts on this, I'll need to consult mongoose documentation ..
If you go with a "throw on error" style option, it would be prudent to enable by default.
So the option would rather be disablePluginForLean
or something like that and it would ofc default to false.
This would ensure backwards compatibility and the user should need to explicitly ignore the error.
from mongoose-patch-history.
Related Issues (20)
- mongoose 6.4.4 not work HOT 4
- Close version with latest changes HOT 2
- Patches are not deleted if I use deleteMany({}) HOT 1
- An in-range update of mongoose is breaking the build 🚨 HOT 28
- Cannot read property '$__' of undefined HOT 1
- An in-range update of fast-json-patch is breaking the build 🚨 HOT 4
- Usage of old mongoose index practice HOT 2
- Is there an option to track author of changes HOT 5
- An in-range update of mongoose is breaking the build 🚨 HOT 45
- Bluebird promises module is a run-time dependency!
- Is this repo still active? HOT 9
- Breaking change in new released version v1.4.0: MongoError: unknown top level operator: $push HOT 6
- Cannot perform an `add` operation at the desired path HOT 6
- findOneAndUpdate with options { new: true, rawResult: true } throws Error HOT 6
- Bug: With the plugin, updateOne hangs, if nothing was found HOT 8
- Timeout upon saving a new document HOT 7
- Not capturing delete events. HOT 7
- @types/mongoose-patch-history HOT 4
- Make name of internal data() method configurable
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mongoose-patch-history.