Live data from Hacker News

CodernityDB — pure Python, NoSQL, fast database

labs.codernity.com

31–40 of 52 posts

Re: CodernityDB — pure Python, NoSQL, fast database

#31

"CodernityDB pure python, NoSQL, fast database" Is the fact that it is written in "pure Python" really the most important thing to reenforce after the name of the product itself? Why would I use this over established products like Riak, Redis, MongoDB, etc?

Python is on almost every host out there now. Riak, Redis, and MongoDB are not, and on many hosts you won't be able to compile them from the source. So yes, that's relevant.

What platforms are people trying to run Riak, Redis, and MongoDB on where a package is not available, or a compiler is not available?

add repository.... {apt-get,yum,brew,port} install {mongodb,riak,redis}

I see little benefit in compiling any of these products from source.

Re: CodernityDB — pure Python, NoSQL, fast database

#32
post #21

Earlier quoted context omitted.

While this is true, it's to the detriment of their project not to have at least some English docs. It grants them the largest possible audience[1] for their project. Generating interest in their tool is one of the things that they need to do if they want it to be a successful open source project. [1]: I guess it's possible that 'Chinese' might be close too, but I have no idea how the different dialects (Mandarin/Cant…

> [1]: I guess it's possible that 'Chinese' might be close too, but I have no idea how the different dialects (Mandarin/Cantonese) would affect this. Cantonese isn't written down, strictly speaking; when you write Chinese, there aren't dialectic differences.

nginx didn't have english docs until 2 years after the project launched. Full story from Igor Here: http://www.ruby-forum.com/topic/151853

Also: Don't blame people for english lang proficiency.

Re: CodernityDB — pure Python, NoSQL, fast database

#33

A cursory glance through the code revealed a bug: https://bitbucket.org/codernity/codernitydb/issue/1/_rev-not...

By the way, the risk of a collision with 10 times more members is much more than 10 times as likely, due to the birthday paradox.

Yeah, I realised I got the probability wrong but haven't written a follow up (typing on my phone is tough, writing code is impossible). The probability of being able to update an old version of the document, is simply 1/ 65536. That's a very high probability given thousands of documents or a modest number of competing updates. The biggest issue is that it's undetectable and non-deterministic: the update that should fail will succeed silently and it can happen at any time.

I'll re-open the bug in the morning with a proof-of-concept.

Re: CodernityDB — pure Python, NoSQL, fast database

#35
post #15

The only thing that turns me off to a product more than a poor website is poor English in the documentation. If English isn't your primary language, PLEASE get someone that speaks it fluently to either write your docs, translate your docs, or edit what you've written.

They are nice to write the documentation in poor English, they could launch the product only with Polish documentation and then you would never be able to use it before someones translates it.

> they could launch the product only with Polish documentation and then you would never be able to use it before someones translates it

This is true. It is also true that I am not able to use it at present because I don't understand the documentation.

A large part of modern programming is getting one's code to work with external libraries. For this to be a joy (and not a pain) the library's API should be simple and the documentation well-written.

I'm sure I could understand this library, if I put effort into it. However doing that has added problems -- I might subtly misunderstand it in ways that my code works most of the time but not always. And why should I bother? Python comes with multiple ways of storing data, such as sqlite, which I've used before and like.

This is not to knock the people behind CodernityDB which for all I know might be an excellent product. But at the moment it's not one I would consider using.

Re: CodernityDB — pure Python, NoSQL, fast database

#36

"CodernityDB pure python, NoSQL, fast database" Is the fact that it is written in "pure Python" really the most important thing to reenforce after the name of the product itself? Why would I use this over established products like Riak, Redis, MongoDB, etc?

For me, the db being in pure-python means a db that can be easily extended or augmented. If you have some quirky requirement your options are 1) implement this in the client, or 2) modify your db. Option 1 is probably what most people opt for (how many people have the confidence to dig into postgres/mysql source, how many of these people want to?), and a pure-python db makes option 2 more feasible.

Re: CodernityDB — pure Python, NoSQL, fast database

#37

The only thing that turns me off to a product more than a poor website is poor English in the documentation. If English isn't your primary language, PLEASE get someone that speaks it fluently to either write your docs, translate your docs, or edit what you've written.

pretty rude. why don't you offer to help?

Re: CodernityDB — pure Python, NoSQL, fast database

#38
post #10

"CodernityDB pure python, NoSQL, fast database" Is the fact that it is written in "pure Python" really the most important thing to reenforce after the name of the product itself? Why would I use this over established products like Riak, Redis, MongoDB, etc?

> Is the fact that it is written in "pure Python" really the most important thing to reenforce after the name of the product itself? It's definitely a selling point for Python programmers, because it's so easy to use with your Python projects. You just set the package requirement and you're done, it will work in the same environment wherever your app works, upgrades are a piece of cake, no need to worry about platfor…

The thing I like most in python is not python itself but a "pythonic way". "Pythonic" > Python.

In my opinion, it's not "pythonic" to use DBMS, just because it written in python.

So the "selling point" is flawed.

Disclosure: I'm using python since 2006. I've made a lot of evangelizing it. It is my weapon of choice for many tasks. And I will never use python for many other tasks. (Don't tell me about PyPy or Stackless)

Re: CodernityDB — pure Python, NoSQL, fast database

#39
post #38
post #10

Earlier quoted context omitted.

> Is the fact that it is written in "pure Python" really the most important thing to reenforce after the name of the product itself? It's definitely a selling point for Python programmers, because it's so easy to use with your Python projects. You just set the package requirement and you're done, it will work in the same environment wherever your app works, upgrades are a piece of cake, no need to worry about platfor…

The thing I like most in python is not python itself but a "pythonic way". "Pythonic" > Python. In my opinion, it's not "pythonic" to use DBMS, just because it written in python. So the "selling point" is flawed. Disclosure: I'm using python since 2006. I've made a lot of evangelizing it. It is my weapon of choice for many tasks. And I will never use python for many other tasks. (Don't tell me about PyPy or Stackless…

You make an excellent point, but when working in Python there are advantages to tying in to tools that are also written in Python. They will tend to be easier to integrate into your project than non-Python code[1] and more than that will generally be easier for you to extend or tweak[2] if you run into a case where you have to "look under the hoos" for some reason.[3]

[1] Python works well with other languages of course, and is often used as a "glue" between other components.

[2] This assumes that you know Python better than whatever language it was made in, but for many cases that will be true.

[3] I often like to look at libraries just to understand how they work, but that is different. There are often cases, especially where the tool uses some abstraction that can leak, where you need to look under the hood just to get things working.

Re: CodernityDB — pure Python, NoSQL, fast database

#40

"CodernityDB pure python, NoSQL, fast database" Is the fact that it is written in "pure Python" really the most important thing to reenforce after the name of the product itself? Why would I use this over established products like Riak, Redis, MongoDB, etc?

Although pure python seems great for some apps, for a piece of software I'd like to be highly optimized, it seems to hit the wrong sweet spot -- it means a larger memory footprint and less robust multi-threading than other pure language implementations. When things need to work fast and tight in python, most implementations duck down to C, like numpy and scipy. Or maybe I've been out of touch with improvements to CPython?
Post reply on HN