There's already an (albeit deprecated) debugger package called pydb (<a href="http://bashdb.sourceforge.net/pydb/" rel="nofollow">http://bashdb.sourceforge.net/pydb/</a>). It would be good to choose a different name for this, most importantly because `pip install pydb` is already taken
It might not hold up to heavy use cases, but I can already imagine a bunch of ways this would make my life easier (I use Python scripts to handle a bunch of social media stuff and basic analytics, for instance, where I use either text files or some other proxy to handle state.)<p>The only request I'd have is a syntactically saccharine way of spinning up the server within the client itself, which is in general an awful idea but would make my life easier for toy use cases.
I wrote a similar library -BlitzDB- a while ago:<p><a href="https://github.com/adewes/blitzdb" rel="nofollow">https://github.com/adewes/blitzdb</a><p>It's a pure Python database engine with a MongoDB-like query engine and support for three different backends: File (native), SQL (via SQLAlchemy) and MongoDB.<p>The library transparently translates a large number of MongoDB queries into SQL or its own native storage backend, and when using the SQL backend it can do things that MongoDB can't, like queries spanning multiple relationships.<p>The latest version is not fully documented yet but I'm using it on several production projects myself. I'm looking for a maintainer and contributors btw, so if you're interested feel free to get in touch with me!
What's the purpose/gain of layering ZMQ into this? I read the architecture bit but I'm still unclear as to what benefit this brings. I guess it allows for multiple clients to use the database at the same time? I can see how the queueing thing is useful for writes if you don't want to have to handle more than one at the same time for the sake of complexity, but wouldn't doing this for reading slow things down unnecessarily?
Will this code not cause issues? I know that you aren't modifying args or kwargs, in the _run method, but it just seems like a potential point of failure or a python anti-pattern<p><pre><code> def _run(self, func=None, args=(), kwargs={})</code></pre>
Seems like this could be a good idea for small personal or temporary dashboards. Especially those with viz powered by packages that work natively with Python data structures like bokeh or plotly .
The syntax reminds me of PyDal:
<a href="https://pypi.python.org/pypi/pyDAL" rel="nofollow">https://pypi.python.org/pypi/pyDAL</a>
<a href="http://www.web2py.com/books/default/chapter/29/06/the-database-abstraction-layer#Shortcuts" rel="nofollow">http://www.web2py.com/books/default/chapter/29/06/the-databa...</a>
vanilla zeromq is a pretty bad choice for any database. zmq explicitly makes no guarantees about reliable delivery, so losing random inserts or queries here or there would be considered acceptable.<p>subscribers also lose the first few messages the publisher sends, unless you make sure you start the subscriber first. The publisher will make no indication of which messages are lost and which ones have actually been sent to someone:<p><a href="http://zguide.zeromq.org/page:all#Getting-the-Message-Out" rel="nofollow">http://zguide.zeromq.org/page:all#Getting-the-Message-Out</a><p>I would suggest building something on top of request-reply instead: it's actually possible to get build reliable delivery on that.<p><a href="http://zguide.zeromq.org/page:all#reliable-request-reply" rel="nofollow">http://zguide.zeromq.org/page:all#reliable-request-reply</a>
Looks like a better shelve <a href="https://docs.python.org/3.6/library/shelve.html" rel="nofollow">https://docs.python.org/3.6/library/shelve.html</a>