Show HN: Pydb – a lightweight database with Python syntax queries, using ZeroMQ
github.com
github.com
I'm open to suggestions for names if anyone has one. (Although I guess it'd be nice if the top discussion thread wasn't about naming.)
EDIT: I just saw you opened an issue on github so I'm happy to take name suggestions there.
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.
If the client could start servers (other than by importing from server.py), what would be the intended outcome if two clients try to spin up servers at the same time? Otherwise would a file lock do? In that case, just file locking combined with pickle could possibly be enough for your needs.
On account of starting / stopping the server... I personally don't care if functionality is there or not as I can always start server manually on dev machine, and it should be started differently on production machines anyway. But that's just my opinion.
https://github.com/adewes/blitzdb
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.
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.
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!
For speed, the idea is that you could potentially have multiple read-only servers answering queries simultaneous (all taking from the dealer). This isn't fleshed out yet. It possibly involves splitting requests into two queues for read and write requests (instead of only "run").
I'd be interested in hearing any info about potential slowdowns if you have them.
> I'd be interested in hearing any info about potential slowdowns if you have them.
I figured if you have a central queue that everything needs to go through then you'd also be limited to a single read at a time. But if you can have multiple read-only secondaries then that's unlikely to be an issue.
pip install -e git://github.com/asrp/undoable#egg=undoable
tells me `setup.py` doesn't exist (because it doesn't). I haven't gotten around to packaging yet not knowing (before today) if anyone's interested.I'll probably look into that soon.
def _run(self, func=None, args=(), kwargs={})I mean I'm not modifying args or kwargs now but if I did later, I could shoot myself in the foot in a not so obvious way. But on the other hand, I don't know a succinct way to express these default values. I'd probably go with `args=None, kwargs=None` and then `args = args if args else ()`.
def func(list_arg=None, dict_arg=None):
list_arg = list_arg or []
dict_arg = dict_arg or {}Instead of checking for any object that evaluates to False, you should explicitly check for None, e.g.
def func(list_arg=None, dict_arg=None):
if list_arg is None:
list_arg = []
... DEFAULT=object() # used for no other purpose
def fun(arg=DEFAULT):
arg_val = {} if arg is DEFAULT else arg def func(*args, defaulted='default', **kwargs):
# args is a list, kwargs is a dict
arg0 = args[0] if args else None
another_kwarg = kwargs.get('another_kwarg', 'default')
print(arg0, defaulted, another_kwarg)
>>> func('one', 'two', defaulted='myval')
one myval default
>>> func(another_kwarg='myval')
None default myval
>>> args = ('one', 'two')
>>> kwargs = {'defaulted': 'myval', 'another_kwarg': 'other'}
>>> func(*args, **kwargs)
one myval othersubscribers 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:
http://zguide.zeromq.org/page:all#Getting-the-Message-Out
I would suggest building something on top of request-reply instead: it's actually possible to get build reliable delivery on that.