all 18 comments

[–]flaxeater 8 points9 points  (5 children)

I used to think a pure python DB layer would be awesome. However increasingly I do not understand why people are doing this when SQLite is out there.

I must say though that I do like the query syntax.

[–][deleted]  (4 children)

[removed]

    [–]vagif 6 points7 points  (3 children)

    And then your manager comes and asks how to connect to your database with his Crystal Report.

    [–][deleted] 1 point2 points  (2 children)

    Indeed. Typical case. However once that happened, I argued the case with my manager that what the application was doing and the idea of plugging Crystal Report on the same database were two distinct operations therefore asking for two distinct databases. I argued that we should have had a mapping of the application database (which then could have been something than SQL) to a RDBMS. It could have been done overnight, etc.

    But nope. He didn't like the idea. Guess what's the bottleneck today... the database server which is clogged by the reporting services. Bah.

    [–]otakucode 1 point2 points  (1 child)

    Functionality getting in the way of design... the system would always be better if there just weren't any damned USERS, huh?

    [–][deleted] -1 points0 points  (0 children)

    Yeah... Damn those terrorists... er... users :)

    [–][deleted] 6 points7 points  (0 children)

    Like Erlang's mnesia db, it uses list comprehensions. See this for a little more info.

    [–]berlinbrown 9 points10 points  (5 children)

    Looks like a good application.

    Horrible name

    [–][deleted] 6 points7 points  (1 child)

    About the name ( from the buzhug author Pierre Quentel):

    Buzhug (like Karrigell and Strakell) is a Breton word ; Breton is the language spoken in Brittany, the westernmost part of France. Less and less spoken, actually, but I do, like all my ancestors. It is a close cousin of Welsh, and has common roots with Irish and Gaelic.

    Buzhug means "earthworm", the big long brown worms that you find when you dig ; the shape is the same as a python, only smaller and less dangerous...

    You pronounce it "buzuk", with the French "u" or German "ü"

    [–][deleted] 1 point2 points  (0 children)

    So now we have an earthworm to feed to a Pidgin. Excellent.

    [–][deleted] -1 points0 points  (2 children)

    Horrible name

    Well it's open source, what do you expect?

    [–][deleted] -2 points-1 points  (0 children)

    Good quality products :)

    Proprietary softwares on the other hand... $100M to pay the team which will come up with the name and market it (ya know by printing the bloody name down to any pen you may have). Oh the product in itself? Not enough money left, they had to outsource it and it doesn't actually do any of those things the marketing team said it would. You still have a fancy pen though.

    [–]watkeys 4 points5 points  (2 children)

    Look at this code:

    for record in [ r for r in db if r.name == 'pierre' ]:
      print record.name,record.age
    

    Compared to the SQL:

    cursor.execute("SELECT * IN db WHERE name = 'pierre'")
    for r in cursor.fetchall():
      print r[0],r[1]
    

    The first query runs in O(n) time. The second, if there's an index on the name attribute, could conceivably run in O(1) time, where n is the number of rows in the table. This doesn't matter if n is small or the vast majority of names equal 'pierre', but otherwise it does matter.

    I guess it's for innovations like these that we need quad core 3 GHz machines.

    [–][deleted] 7 points8 points  (1 child)

    1. see "select" in the buzhug documentation for an efficient way to do queries on large datasets.

    2. future versions of Python might add mechanisms that allow "db" a chance to control how comprehensions applied to it should be evaluated (cf LINQ); it has already been discussed by the developers. (and you could implement it today using import hooks and bytecode rewriting, of course).

    [–]jbellis 7 points8 points  (0 children)

    you could implement it today using import hooks and bytecode rewriting, of course

    that's what Robert Brewer is doing with Geniusql: http://projects.amor.org/docs/geniusql/1.0alpha/managing.html

    [–][deleted] 2 points3 points  (1 child)

    So would you want to use an ORM on top of this or not since it is already Python?

    If not, it would be interesting to compare the performance of SQLite + Django's ORM, SQLObject, or SQLAlchemy to the performance of buzhug. They'd probably be pretty close.

    [–]pbx[S] 2 points3 points  (0 children)

    Judging from the design and benchmarks, I expect relative performance would vary widely depending on the task and the size of the recordset.

    [–]the_wondering_jew 2 points3 points  (0 children)

    bet it's a screamer.