ilovetux / data_store Goto Github PK

This is a feature request. I would like to be able to pass in a compiled regex into the spec document and match based on that.

Also implement doc tests, to regression test the documentation

Would be nice to have these things:

1. Instructions on how to run your tests.
2. a requirements.txt so that I can quickly install requirements if I am using a virtualenv.
3. Add a test_suite into the setup.py so that tests can be run via python setup.py test

Currently the api (the wsgi application) can handle just about every task you would need, but there is a little more to do including:

• pull through the ability to sanitize and/or encrypt fields
• pull through the ability to order by
• enable https
• enable persistence
• enable loading persisted data after service is restarted
• support basic auth
• package as a windows service
• package as a linux daemon
• support sending pickled objects over the wire instead of JSON payload (possible)
• Update all documentation
• put an image on docker hub

I could really use some guidance here if someone is actually using this and would like certain features added, please don't hesitate to submit an issue or comment on an open issue.

I see that there were over 500 downloads from pypi in the last week, so I think it's time to start putting a little more time and effort into this project. In particular I will be spending time implementing the following features:

1. Documentation - There is none right now. I propose that I implement the documentation as an IPython Notebook which I will host on Wakari. If there is a better idea for implementing the documentation, please feel free to comment on this issue.
2. Allow Store constructor to accept either a list of records to add to the store or a path to a file which is a persisted Store
3. Allow Store.find and Store.find_one to accept a callable as the value of a field match. The callable would accept one argument (the value of the current record) and return either True or False (referring to whether the record should be included in the results.
4. Allow field level sanitation of records through a keyword argument in find and find_one
5. Allow field level encryption (using xor with a password)
6. Allow encryption of entire persisted Store (using xor with a password)
7. Split the tests out into separate files for better organization

If there are any features you would like to have included please don't hesitate to submit an enhancement request here in github issues or even better to fork and submit a pull request.

I was just looking at this, and I realized that it's just all wrong...Ill redesign and post back here.

Implement rollback on failure

Possibly an install mechanism which would install itself as a windows service or a linux daemon (with init script)

We need a sort method which returns a new Store created from the current Store, but sorted by a by clause (read parameter).

currently we are using xor and base64 to obfuscate strings, while this could be considered secure if the users decided to use One Time Pads, currently there is no way to enforce this. I propose using AES encryption using the method described here. This will be done in preparation of version 0.7.0

The api is unsecured, I will use bottle's built-in support for basic auth to allow for users and permissions.

I will also take this opportunity to allow for per-user data stores. Each user will have a python "shelve" file to store their data, and when accessed the authenticated user name will be used to build the filename, so they will automatically be guaranteed to only get their data.

Once I update the documentation I believe that we will be ready for the 0.6.7 release.

This would allow us to easily deploy a REST service in a planned and automated way using a nice containerization engine.

I will fill in the details shortly

we will need to implement a simple client. Some initial thoughts on implementation:

1. One in python one in javascript (perhaps java [perhaps jython support])
2. Should simply map the rest api, possibly implement client side cacheing of results
3. I would like this done in two layers, one is a reusable library which can be used to create clients of a rest api and another layer which uses the first library to implement our client

Should be pretty simple, just implement a series of locks.