Factor currently has bindings to SQLite and PostgreSQL. On top of these bindings, a simple Object-Relation Mapping (ORM) is built. This ORM is currently very limited, with no support for joins, etc. A redesigned database library could have roughly the following architecture.
On the bottom, there should be an API similar to Perl's db library, providing injection-proof interpolation into SQL statements, an API to manage sending SQL statements to the database and iterating over the results.
A cross-database layer can be built on top of this, where instead of building strings, you build objects that represent SQL queries. This makes them easier to programmatically generate.
The object-relation mapping should be rebuilt on top of FQL, so that it does not need multiple backends as it has now. Support for important database features like joins should be added.
The student will learn about SQL and the design of high-level APIs.
Several Factor applications use the existing database library, and an improved one would allow the use of more powerful database features in a high-level way.
This revision created on Fri, 13 Mar 2009 17:31:37 by littledan