I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way.

gforge_base/evolvisforge/gforge/common/include/utils.php:1009

I was really, really bad at writing parsers. I still am really bad at writing parsers.

gforge_base/evolvisforge/gforge/common/include/minijson.php

I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I'll just restart apache every 10 requests.

gforge_base/evolvisforge/gforge/www/pm/t_follow.php

We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all.

gforge_base/evolvisforge/gforge/www/pm/t_lookup.php

I think people like Rasmus explain a lot about the poor design and the many implementation flaws of the PHP programming language.

Thanks as well to Benny Siegert who provided the quotes.

• databases/apache-cassandra: Highly scalable, distributed structured key-value store
• databases/libcassandra: C++ interface to Cassandra
• databases/p5-Net-Cassandra: Perl5 module for accessing the Cassandra database
• databases/py-cassa: Python client library for Cassandra
• databases/ruby-activerecord-cassandra: ActiveRecord Cassandra adapter
• databases/ruby-cassandra: Ruby extension for Cassandra

Apache Cassandra is a next generation, No-SQL, non-relational distributed database. Unlike SQL databases, it behaves more like a key-value store and can store nested data structures. Cassandra is already in use by a number of large web sites, and has clients for a number of programming languages, like the ones mentioned above.

If you're expecting content there yet, you're a tad too early. The idea is merely a sketch at this point. So far my plans comprise an installation of Gitorious so I can migrate my projects away from Github to my own hosted place. Of course, bsdprojects.net was meant for this initially, but it's less private.

The current idea of the domain looks as follows:

The spec files etc. would eventually end up on git.ancient-solutions.ch.

Anybody got a cthulhu logo?

In Oops, we did it again, Monty names a number of these bugs and outlines variety of bad management decisions which have lead to the current situation, and which apparently have lead to similar situations in the past.

To me, it does not really come as a surprise. As you may or may not know, I have been following the MySQL company, community and products for years, and haven't seen too many different types of releases so far. In any case, I strongly support the suggestion of Monty and also strictly recommend staying with MySQL 5.0 for now &mash; or to migrate to PostgreSQL, if possible.

Drizzle is a clone of MySQL 6.0 where any type of useful features has been removed. Its focus lies on Simply design for ease of installation and management (sic). There is a large list of features which have been removed:

• Stored procedures, ok, they are not usually very useful in well-designed software, or maybe they are?
• Query caches, so that queries will have to be reparsed and reexecuted every time, slowing down normal operation significantly
• Prepared statements, slowing down repeated operations significantly and re-opening the doors to SQL injections
• Views, ok, I admit I have started to dislike them myself
• Triggers, because who cares about data integrity and the likes
• Grants, who needs permission management anyway? Any attacker should be able to enjoy full damage capability
• Some storage engines — I think this one slipped through, as it is not a hilarious idea

At the first glance I thought that someone was about to commit a devastating stupidity, but then, reading through the web sites and source code I am now convinced that this is an artistic act, aimed at making fun of the puritan MySQL community. Someone has proved a really great class of humour, especially in the way he imitates fresh students who fork software projects despite having no idea of what they're talking about. Also, the spelling mistakes look really authentic. I had a very good laugh.

Thank you a lot, Mr. Brian Aker, you're really a great commedian of the Open Source community!

Unfortunately, it appears that this pony is not even free.

The fact that the Python core team deliberately keeps breaking compatibility for Zope is probably bad enough, but at least SQLAlchemy appears to work well enough with the various versions. Well, but how does it work?

The answer is: bizarre.

Never trust the database to get sequences right!

The first thing I discovered was with PostgreSQL and sequences. Some tables use sequences for creating their primary key, which is then going to be a 64-bit integer. This is done automatically by either not naming the primary key column on insert, or by using the keyword DEFAULT.

Looking through the debug output, however, items like these can be spotted:

2008-11-04 09:26:24,258 INFO sqlalchemy.engine.base.Engine.0x..d0 select nextval('data_from_box_id_seq')

This is wrong on a number of levels. At this point, SQLalchemy manually queries the next value returned by the sequence for the id column. This value is consequently used in the insert statement for the id column. This breaks the atomicity of the insert statement — rather than letting PostgreSQL handle things internally as it's supposed to, the insert statement is artificially split into two statements. Of course, this also means that two SQL operations are performed, which almost doubles the network overhead (especially over encrypted connections).

The most likely reason why this is done is to have the row ID of the newly inserted row for use in the client side object representation. However, PostgreSQL has two much better mechanisms achieving the same: Firstly, the ID can be queried using the last_insert_id operation, or, even better, everything can be handled in one statement by using the RETURNING keyword:

INSERT INTO data_from_box VALUES (DEFAULT, something, else) RETURNING id;

Prepared statements are for the weak and timid

An even more bizarre affection manifests itself in the support for MySQL. Rather than to make use of the prepared statements, which are mandated by the API specification, SQLAlchemy attempts to reproduce prepared statements in the SQLAlchemy code, and to naturalize SQL statements manually. Then, the resulting statement is PREPAREd and EXECUTEd.

This of course constitutes a duplication of functionality, and more than this, the SQLAlchemy users are now prone to SQLAlchemy prepared statement naturalization bugs which cannot really occurr in SQL prepared statements (because they are never synchronized into a string but used as-is).

Overall, it is very hard to say what the SQLAlchemy developers had in mind, but it seems clear that it was nothing useful.

• iter(collection) -> iterator
• iter(callable, sentinel) -> iterator

The first call is rather unproblematic for sure. It calls a class method, it gets its object and that's it.

The second variant is however utterly useless. The callable is not called with any object — in fact, the call to iter does not even know what object is being iterated. This requires the programmer to store the state externally in some kind of global variable, or not to have any state at all. The latter would render the iterator rather pointless, since a crucial part of the purpose of an iterator is to externalize the state.