*This project is no longer actively maintained. If you'd like to become the maintainer, please let us know.* ZeroDB is an end-to-end encrypted database. Data can be stored and queried on untrusted database servers without ever exposing the encryption key. Clients can execute remote queries against the encrypted data without downloading all of it or suffering an excessive performance hit.
Supporting 3.4 would require more work (e.g. we use % formatting for bytes objects, which was added in 3.5), but wouldn't be too hard if there is a demand.
Requires a forked repoze.catalog (https://github.com/micxjo/repoze.catalog) to actually run under python3, but still work on python2 with the version in PyPI. Will see about getting those changes merged upstream, but as discussed it might make sense for zerodb to fork repoze.catalog anyway.
Separate pull requests for zerodb-server and zerodb-benchmarks forthcoming.
Most of the changes are pretty straightforward, though 5a06504 is a little subtle. Because of how tuples are compared, the last line of IndexQueue.optimize() requires Model's to be comparable, which is true in python2 because all classes have an implicit __cmp__(), but is not true in python3. I defined Model.__lt__() to reproduce the behavior under python3 but am not familiar enough with the codebase to know if this was wise. The comment in optimize() suggests that the sort is really about sorting by operation, in which case maybe we should be passing key=lambda x: x[0], removing the need for Model's to be comparable and for that matter removing the overhead of comparing them here (e.g. what if someone overrides __cmp__()/__lt__() on their Model subclass in a really slow way).
Adds python3.5 support.
%
formatting for bytes objects, which was added in 3.5), but wouldn't be too hard if there is a demand.Most of the changes are pretty straightforward, though 5a06504 is a little subtle. Because of how tuples are compared, the last line of
IndexQueue.optimize()
requiresModel
's to be comparable, which is true in python2 because all classes have an implicit__cmp__()
, but is not true in python3. I definedModel.__lt__()
to reproduce the behavior under python3 but am not familiar enough with the codebase to know if this was wise. The comment inoptimize()
suggests that the sort is really about sorting by operation, in which case maybe we should be passingkey=lambda x: x[0]
, removing the need forModel
's to be comparable and for that matter removing the overhead of comparing them here (e.g. what if someone overrides__cmp__()
/__lt__()
on theirModel
subclass in a really slow way).