This week PostgreSQL.org has announced the release of 9.0 beta 1, showing that the project continues to advance rapidly (8.4 went GA less than a year ago).  The new beta release includes quite a few exciting and long-awaited features, including, but not limited to:

• New, easy to use binary replication
• Continuous archive to warm standby or read-only slaves
• Anonymous blocks
• Mass grant/revoke operations
• 64-bit support on Windows
• Named parameters for stored procedures
• Per-column and conditional triggers

Josh Berkus has written a post encouraging users to test many interesting but perhaps less-publicized features in PostgreSQL 9.0.

Devrim Gunduz has written a blog on how to install PostgreSQL 9.0 beta 1 on your Fedora/CentOS/RHEL Linux server.

The PostgreSQL wiki has a helpful article on How to Beta Test.

You can download PostgreSQL 9.0 beta 1 source at postgresql.org, or binaries for Linux, Mac or Windows at enterprisedb.com (you’re invited to register to gain access to tutorials, but you can download the software without registering).

When I arrived and began programming Web applications, I took a look at CakePHP, and suggested we use it. Soon, it was implemented for basically all new development projects. I quickly realized, though, that I had a huge knowledge gap. Sure, I know what object-oriented programming is, and even done a bit of stuff previously, but when my boss suggested we might use things like an observer pattern on some legacy code, or when he talked of extending CakePHP’s controllers in various ways, I knew I’d need to expand my skills.

And even with the database side of things, where I felt a bit more comfortable, I found that my knowledge of SQL was a bit rusty in spots—such that I couldn’t decide if what CakePHP was doing (say, with joins) was correct or whether I’d need to do things differently.

Frameworks like CakePHP, Zend Framework, and Symfony allow you to quickly and easily write a “real” application, but in doing so they tend to shield you from things like raw SQL and obviate the need to manually load or extend classes, for example. I contend that this is a good thing, but only if you understand the “guts” of the system—that is, OO and SQL, for example.

Why? Consider what happens if your framework loads data into a variable in a completely unexpected way. If you don’t understand the SQL that’s going on under the hood, what chance do you have of determining whether the framework is wrong—or perhaps you’re not calling the data in the right way?

In a similar vein, knowing how to program in an object-oriented way is also vital. I’ve looked at the Lithium framework recently, and confess to not understanding a lot of what’s going on. Sure, there’s some documentation, but I’m certain my learning process would be helped if I understood things like singletons, or lazy loading, or even anonymous functions.

This goes beyond mere debugging or learning new technologies. As in the example I gave earlier, it’s quite possible that you’re going to hit a point at which you want to do something the framework doesn’t do natively; in this case, your OO skills come into play, letting you get the job done. Or what if the framework can’t handle the poorly designed legacy database you inherited? Suddenly your SQL-fu doesn’t look so useless, since you’ll be able to write occasional custom queries when the framework falls flat.

But even beyond that, there will be times during which you can’t (or don’t want to) use a framework. I recently took a look at CouchDB and PHPillow, and I confess that I still can’t get PHPillow to work. My OO chops are simply not up to par. That experience taught me that I really need to start taking my favorite PHP book to bed with me a little more frequently.

So, even if you use a framework, take the time to get to know object-oriented programming and SQL (useful even if you’re using a document-oriented database, I think). They truly form the building blocks of programming.

Image of building blocks from Flickr user Artful Magpie. Published under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.0 Generic license. http://www.flickr.com/photos/kmtucker/3355551036/

Microsoft is planning on releasing CTPs regularly, so be sure to send them feedback on their SQL Server Driver for PHP forum or by commenting on the team’s blog. More information is available by visiting SQL Server’s Connect site.

The basic idea

Thanks to the wide support by hosting services, PHP can run nearly everywhere in the web and has a stable and high performance driver for Oracle databases.

This approach to user interface is sound: the Oracle development model prescribes to keep all the business logic in the database via its PL/SQL language, an extension to the standard ANSI SQL. Every database vendor has its proprietary extensions to SQL, but Oracle and PL/SQL are famous for their extended set of features and expressive power. Similar PHP code generators are available for other database vendors, which often lack the necessary support for the encapsulation of business logic.

Issues with generation approaches

Programming without programming is an old idea and has never been a full success. In addition to the standard graphical customization, there are many aspects of the development of the user interface which deal with presentational logic, which does not belong to the database side and should be dealt with by the UI layer.

For example, the localization of dates and times in a format convenient to the end-user it’s a common case of presentational logic: the underlying representation in the database it’s always the same, but the data is translated for the sake of a smooth user experience. Oracle PHP Generator, at least in its full version, supports many of these caveats, but one can never be sure that the generated interface will support all the needed features. Generated code should never be modified by hand, due to the issue of keeping customizations during a subsequent regeneration (performed for example because of a change to the database schema.)

The tool

This particular execution of the UI generation idea is a bit off track. For example, the product runs only on Windows via an user interface. This makes it difficult to use it in a continuous integration cycle, or in any kind of automated process. The products of code generation have to be kept in sync with the back-end they refer to.

Of course Oracle PHP Generator is the right product for data-driven applications, which work mostly with CRUD and orthogonal requirements such as authentication and access control, and leverage the Oracle support for business logic in the persistence layer — if you happen to like it — avoiding unnecessary duplication. However, like all generated UI products, it shows its limits when it comes to support unusual features in the UI.