Quote of the Month

"For each elegant solution, there's one show stopper that prevents you from using it."

Remember that one, boys and girls. Today I was hinted of a function that could solve a lot of the problems I described yesterday, especially the one where I could determine which column comes from what table. Namely mysql_field_table(), which does exactly that. I was somewhat astonished that PostgreSQL had the same function, which unfortunately queries the database metadata about the names of the columns, but that's better than a foreach-loop in PHP. But the show stopper was SQLite's deficiency of said function or equivalent.

While SQLite is somewhat of a marginal database when it comes to popularity, I've grown to liking it under this project. It's respectably fast (the major surprise) and it's very widely available. Many website space providers charge extra of MySQL or PostgreSQL, but they most probably have SQLite support (unless they're cheap and wants to rain on your parade, just to get more money out of you). So that's why I want to have SQLite support included in this - the framework's greatest requirement is the support for SQL, and with SQLite, you get SQL support with virtually any PHP-installation.

While I'm at it, I can openly say that what I'm doing with Models and Fields is practically a variant of Propel. With some regards, it's not as robust and fancy as Propel, but on other areas it's more intuitive (definitions in native PHP code instead of XML *shudder*) and flexible (faux custom aggregate functions on a per row/model basis).

Now, back to the drawing board. I have stuff to think about.