Hi again @seladb =) I beleive we talked briefly about doing cargo audit in CI. Well now I've set it up for my little project over at https://github.com/jensim/bitbucket_server_cli and i think it works great so far. Wanna try it out? Best regards Jens

Wanted to use pickleDB, but trying to avoid having quote + syn in my build tree. This change optionally reduces the number of deps for the library to one, with similar performance to bincode according to the test suite.

I was surprised to discover that PickleDbDumpPolicy::DumpUponRequest still causes a dump on Drop. It's not clear to me if this is intentional or a bug, so for now I propose a new policy that removes this unexpected implicit dump for applications that wish to opt-in while retaining the existing behaviour for other users of PickleDbDumpPolicy::DumpUponRequest.

This PR removes this unexpected dump.

There is almost no error/exception-handling code in Python version's Pickledb.It works because Python use try/except and exception to deal with errors and failures.You can always put a try/except block in your code that calling the Pickledb's API.Which will handle the exceptions raised from the internal of the Pickledb.In Rust's version,there is the same situation.But Rust don't use exception,is it a good choice to just panic the thread if something went wrong in internal code.

This question is raised because I saw so many unwrap and expect in Pickledb-rs's code.Would it not be more robust if use error and option?Any plan for this?

This branch just does the work related to allowing the feature flags to actually be used. Currently only some combinations will work, this pr makes it so that any combination of the serialization types may be used.

Am really happy to have come across this, am an aspiring Rust developer and it really appeals to me, and so this year i want to write a small database system and so i have been researching on the matter, and have truly taking a liking to this, seems simple and useable, and gentle to use to,

And so, i would love to inquire, what would be the difference between using this crate vs simply writing and reading to a file probably serializing with json, cause what am getting so far is that either files would be loaded to memory at runtime and neither are accesed from disk, well, one difference i do spot is that for sure handling the data should be much easier using this and also it has a few more in built features to take advantage of, so yeah, seems pretty neat, could you kindly enlighten me more on this matter, would be highly appreciated,

I've made multiple commits to this PR, any of which can be removed or made into standalone PRs if you prefer.

The main intent was to change the two instances of lextend() to take references to values rather than actual values. I ran into a few other fairly trivial issues while doing this and bundled fixes for them all into this PR.

Flaw found in transitive dependency failed my build https://travis-ci.org/github/jensim/bitbucket_server_cli/builds/667567270 I added a audit step to the build as well, if you think its smart?

This allows us to run the examples by calling e.g. 'cargo run --example hello_world'

It also means the examples get compiled when calling 'cargo test'.

Resolves #23

Not sure I like how I had to handle most of the match blocks, since I couldn't find an easy way to disable enum fields with features, but it works. Brings size of hello_world example from 1.2 MB to 670 KB, and lists from 1.2 MB to 673 KB on macOS.

I added features for the different serialization methods, to lower the library size and necessary dependencies. Default is json. Unfortunately running the tests is only possible using all features, because of the parameterized rstests. Maybe you have an idea how to solve this problem.