ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
Undocumented no more ..
After I put out my call for assistance for writing MDB2 docs I got a lot of positive feedback from people who wanted to help. Unfortunately nothing concret has materialized. So I decided its time that I jump start the effort by completing the bulk of step 1 in my call to action. The core API of MDB2 is now documented in the official PEAR manual. Enjoy and feel free to expand.
I just tweaked the URLs to specific messages on my blog quite a bit. The URLs that were previously generated as follows:
php|tek wrap up
I spend the past week in florida. First visiting my parents and then spending time at php|tek where I was invited to give two talks. I was quite nervous about the first talk about "database schema deployment". My original intention was to create a working solution to handle scripting the necessary DDL and DML statements to manage schema updates. However while researching the topic I found that its even less trivial than I expected. So during my talk I was mainly giving some basic ideas along with a number of ideas to explore depending on the needs. For example if all you care about is generating DDL then things are quite simple. In the past MySQL indirectly benefited from the simplicity of the database but with foreign keys, views, stored procedures and triggers even generating DDL is not entirely trivial anymore. If you also need DML then things get instantly more complex.
The MySQL platform
Many MySQL critics have complaint about the lacking of key features, scalability and standards compliance. They also often complain about users who fall for MySQL's successful marketing, short of blaming the inherit evil nature of the universe why such inferior technology is so popular.
The top 5 of PEAR bugs
First up if a package is uninteresting or really badly written it usually gets a handful of bug reports and that is it. However if a package is popular or provides a very unique feature it will generate a fair amount of bug reports and feature requests. Unfortunately a fair number are bogus, but obviously there will be a number of real bug reports too. Since this is all open source the time every maintainer has to allocate to a given package varies wildly. So it can happen that after a while if less activity there is a mind numbing bug count for a package that works perfectly well for thousands of users. But probably if the bugs are fixed the package would be even more useful. Especially users coming to a package who find a huge bug count are also scared off .. even if the bug count is just a result of a lot of bogus and/or duplicate bug reports. Its hard to tell for a new comer.