dolthub/doltgresql: DoltgreSQL - Version Controlled PostgreSQL is the PostgreSQL-flavored partner of dolthub/dolt: Dolt – Git for Data and offers the same features, but with PostgreSQL syntax and a binary interface that is compatible with PostgreSQL.
datenbank
dolthub/dolt: Dolt – Git for Data is a SQL database that internally uses mechanisms similar to git, thereby supporting data branches and merges and generally providing the ability to version data in the database and work with history. And like git, it also allows data changes to be distributed via version control. In principle, "slow transaction shipping".
wiki.dbpedia.org : About. Also interesting - here Wikipedia is searched and evaluated for structured information. So, in a way, a Wikipedia for machines is created from the Wikipedia for humans. The whole thing is then pre-packaged with a query language and a suitable web service.
GT.M. And since I'm at it, here's the third open source Mumps implementation. This one was once commercial and became free in 2000. So it has quite a few years under its belt and is not some hobby project by some enthusiasts, but is indeed commercially operated (e.g. for licenses on systems other than Linux and OpenVMS). If you read through the description, they've thrown the whole collection of buzzwords at the tool. Ok, for a language that simply maps its database as global variables into the programs, STM is so to speak already built-in. Even if that might be a bit of a cheat.
Mumps. Yes, yet another implementation that seems to even implement some of the archaic job controls and other obscure artifacts. Well, since NoSQL, Mumps is probably respectable again. However, you have to compile this yourself, as there are no binaries directly available for OSX.
Mumps/II MultiDimensional and Hierarchical Toolkit. Yes, I'm back to absurd programming languages and found a Mumps that is open source and runs on various systems. I don't know what I'll do with it, but it will have to be something painful.
storm-gen - Lightweight DAO generator for Android SQLite - Google Project Hosting. Hmm, I could take a look at that, another ORM for SQLite under Android.
The SQLite RTree Module. And another extension for SQLite, this one a standard extension. R-Trees are tree structures optimized for range queries - that is, range queries such as "is this given rectangle contained in the list of rectangles".
The Gaia-SINS federated project home-page. Just quickly bookmarked in case I need it - spatial data (GIS data) can be efficiently indexed and queried in SQLite with an extension. Since I am a declared fan of SQLite, this is quite interesting. And it is implemented as a dynamically loadable extension (of course, this only works if the SQLite you are using is also enabled for extensions - unfortunately this is often not the case, installation might require a recompilation of SQLite, but it's not that terrible).
ActiveAndroid | Active record style SQLite persistence for Android. Hmm, let's take a look - another ORM for Android, but one with quite interesting syntax. The source also promises a few more things like e.g. Joins. If migrations are also reasonably implemented (this is often lacking), the project could definitely motivate me to switch my little tinkering project.
couchbase/Android-Couchbase. Might be interesting as an alternative to SQLite - especially if you work less with structured data and more with documents. Because CouchDB offers real advantages there. Additionally, you get a sync infrastructure for automatic replication of database changes to a central server. And without having to build text exports with Dropbox-Sync like with SQLite solutions. Although the latter works surprisingly well in the situations where I need it.
Postgres-XC project Page. Multi-Master (Read and Write) Cluster for PostgreSQL. Supports replicated setups as well as partitioned setups (or mixed forms).
mitmel/SimpleContentProvider. Looks like a simple ORM that automatically generates an Android Content Provider. This makes the creation much slimmer in code.
OrmLite - Lightweight Object Relational Mapping ORM Java Package. Let's take a closer look, an ORM that can also be used in Android. Programming SQLite directly with SQLiteDatabaseHelper just isn't that much fun for me. It's a bit too low-level.
SQLite4: The Design Of SQLite4. That sounds very interesting. Especially the first paragraph in "2.0 Overview", where he briefly emphasizes that SQLite3 will continue to be supported and both versions will remain available in parallel. And of course, the various changes that SQLite4 will have compared to the other version, such as the significantly better encapsulation of the engine in its own object. This makes it quite possible to have multiple databases open at the same time without much juggling. And what particularly pleases me: all calculations in Decimal Math and no longer double or float. Sorry, but double (and especially not float) has anything to do in a database, except perhaps as a data type for rare special cases. Also some other nice things in it, for example covering indexes and of course the standard available foreign key constraints.
Make runfcgi fail when database connection is open before fork. This is something I've been chasing for ages, most recently in a few pretty important projects. Flup works by first initializing the WSGI application and then making the forks for the workers with this initialized WSGI application. Unfortunately, we have database accesses during application initialization - as a result, the base process already has an open database connection, and each fork copies these data. But the socket of the connection doesn't go with it - the new process just thinks it's connected, but it's not. Accesses from the new processes then fail with an exception. In the linked patch, you can also replace the raise on the exception with connection.connection = None. This simply discards the connection that is already defective and always builds a new connection in new processes. With this, we have at least been able to fix this in a production environment (with psycopg2) and are optimistic that it will also help in the environment with pyodbc.
SET TRANSACTION ISOLATION LEVEL Transact-SQL. There you can find more information about the isolation level in MSSQL, especially what the snapshot feature means. In principle, this makes MSSQL behave similarly to PostgreSQL.
Enabling Snapshot Isolation - SQLAlchemy 0.7 Documentation. Could this help us? MSSQL seems to have a rather unfavorable isolation level as default. Hmm, we'll probably try it out.
R17 - flexible, scalable, relational data mining language. Looks quite interesting, basically something like a cross between AWK and SQL. The result isn't really pretty, but it seems practical - especially because you can easily use multiple processors, or even multiple machines (implicit parallelization), and thus also quite easily evaluate large amounts of data with ad-hoc queries. Because there is a simple format for passing data to further steps, it can also be easily adapted to new data sources without first running a lengthy export step there.
The Schemaverse. And while we're on the topic of strange projects: someone has programmed an MMO that runs entirely within PostgreSQL. So using pgSQL as the language. Something like a multi-user battleships game. It just runs in a database. And is controlled via SQL.
RavenDB - 2nd generation document database. Bookmarked because I want to check it out in the not-too-distant future. Sounds quite interesting from the features and might be useful for one or two projects that I am currently thinking about.
TL Omnis. And another RAD old-timer - Omnis was one of the first RAD environments I played with and it was quite unusual for its time. No "real" programming back then, just GUI tools for wiring and connecting in combination with calculated fields, but these were very powerful. Very strong focus on graphical tools for various purposes (DB design, relationship management, reports, forms, etc.). It's quite amazing what you can find when you dig a bit. By the way, there is a free standard version of the environment, so you can just take a look at what it can do today.
Bulbflow: a New Python Framework for Graph Databases. Even though I keep thinking that graph databases are so 70s, not everything old is automatically bad - IMS is still around and very interesting for some purposes. And this sounds interesting, something like DBAPI for graph databases, so that you can change the database in your projects without having to rewrite everything completely.
NOSQL Databases. Excellent overview of all available NoSQL databases. Good starting point if you want to inform yourself about the available systems and their orientation and implementation.
Write-Ahead Logging - in SQLite! From version 3.7. This is very interesting because it makes a use case easier - multicore-using applications that want to work with an embedded database. SQLite becomes even more the Swiss Army knife of data storage (and if you take this into account when programming, switching to PostgreSQL for larger installations where the embedded database no longer makes sense is easily solvable).
Oracle Announces Latest Release of Oracle® Berkeley DB - Berkeley DB now has a SQL API based on SQLite. Source code compatibility with SQLite, so programmers can switch if they prefer the much more unstable and vulnerable storage of Berkeley DB and like to repair their databases. Sorry, Oracle, but that's ridiculous. BDB is only interesting for those who have to work with it by force - anyone who wants to switch to BDB today must be crazy. If I'm already programming against the SQLite API, I'd rather use the right tool right away. Yes, of course, SQLite has some bottlenecks when you want to access it in parallel with multiple processes. But I'll let Oracle in on a little secret here: SQLite has such a tolerant SQL parser because you can then write source code whose SQL works seamlessly with both SQLite and PostgreSQL. So if you hit the limits of SQLite - just switch to PostgreSQL and you're good to go.
inessential.com: On switching away from Core Data - scary read. Really - sure, ORMs are nice. And practical. But somehow it scares me when programmers like Brent Simmons (the NetNewswire guy) so openly demonstrate that they actually have no idea what they are doing. Just because you use an ORM to walk through lists of objects and edit individual objects and then wonder about poor performance? And only at the end of the optimization sessions ask the question whether an ORDB is actually the right way? Hello, are you still there? As soon as large amounts of data are involved, the question of mass data processing automatically arises, and if the ORM does not provide usable abstractions, then it is out ... (one reason why I like the Django-ORM, it cooperates well with handcrafted SQL and offers a lot of helper tools via introspection to create these own SQLs as model-abstract as possible). For me, the linked post is on a similar level as Guido van Rossum's "what do you actually use continuations for, I don't get it".
SQLiteJDBC - another JDBC driver for SQLite
SQLiteJDBC - because I am a SQLite fan (if it's too complex for simple text files, SQLite is the next level), and because I play around with Scala and Clojure, I might need this here.
What happened to Hot Standby? - real native synchronization is coming with PostgreSQL 8.5! There are already existing solutions, but native is of course easier for administration. And should finally shorten the silly discussions with the MySQL disciples.
Postgres-R: a database replication system for PostgreSQL - worth a look?
Hyper Estraier: a full-text search system for communities - Full-text database with attribute search and some other nice features - as well as bindings for various programming languages
The Xapian Project - another full-text indexer, this one with various advanced features such as stemming for different languages.
SQLAlchemy README - another ORM for Python, heavily oriented towards SQL and offering a lot of magical syntax. Fascinating how in this area programmers try to abuse every language feature just to avoid writing SQL ...
Dejavu - Trac - another Object-Relational-Mapper for Python. Sounds quite interesting in some points.