joestump.net

So I finally broke down today and started working on my first WordPress plugin. I liked how recent links worked, but I wanted an aggregated list of both links I found interesting and my Flickr photos. I was going to hack the recent links plugin that I had used, but decided against it in the end. In the end I decided that it made sense to store my interesting links on del.icio.us and my photos on Flickr and then aggregate them into a single list, which is what you see now below this post.

This way my photos stay on Flickr and my links stay on del.icio.us, but they show up inline on my blog’s frontpage. I’ve got a few bugs and kinks to work out still, but it’s definitely ready for beta testing. If you are interested in playing with it then give me a shout and I’ll package it up for you to test out.

• Integrates with Flickr and stores photo and tag information into a MySQL table.
• Integrates with del.icio.us and stores link and tag information into a MySQL table.
• Uses PEAR’s DB and HTML_Request packages and PHP5’s SimpleXML extension to seemlessly fetch and cache new content every hour or every time an admin visits the website.

This is a critical update for anyone using DB_Virtual. I wasn’t passing $onoff onto the master DB::autoCommit() function which would effectively break transactions.

Additionally, I was noticing strange behavior when I would do a couple of INSERT queries and then immediately query for that data set after the transaction had committed. What was happening was that the records were created on the master, but the subsequent SELECT was going to the slave before they had propagated to the slave. Basically master/slave latency was breaking the SELECT queries. As a result, I’ve added DB_Virtual::queryMaster(), which acts just like DB::query(), so you can query the master node in such situations.

• Fixed a bug in DB_Virtual::autoCommit() that wasn’t passing $onoff to the master’s DB::autoCommit()
• Added DB_Virtual::queryMaster() so you can send queries directly to the master

Download DB_Virtual 0.0.7

A minor release that addresses a few small bugs and addresses some minor issues with where the database connection is stored. A recommended upgrade for anyone using Framework.

• Fixed bug in query logic in Framework_User::__construct()
• Added Framework_Auth_User
• Added DB::disconnect() to Framework::stop()
• Moved DB connection to Framework::$db so static methods can access the DB connection

Download Framework 0.1.1

This is a fairly critical release that fixes a bug where DB::$last_query wasn’t being returned properly if you ran DB::getOne(), DB::getAll(), etc. Anyone who might possibly be using this is encouraged to update their version.

Download DB_Virtual 0.0.6

Well, for all three of you out there that use Framework you’re in for either a nice surprise or something that will make you want to kill me. I was recently contacted by a company who wanted to use Framework for an upcoming project and was gracious enough to allow me to release some of the upgrades and changes publicly.

The possibly bad news for people who might actually be using Framework is that I totally rewrote some of the core internals. The highlight is that Framework will now load multiple sites without needing multiple installations. Another big upgrade are plugins which will allow you to drop hooks into your modules. All of these new features, of course, are totally beta, but appear to be working pretty well. Read on for the entire list of changes.

• Cleaned up Framework_Session
• Changed Framework::run() to Framework::start()
• Fixed case sensitive bug in Framework_Module::$presenter
• Added multi-site functionality (see Framework_Site class)
• Added a plugin framework (see Framework_Plugin class)
• Added Framework_Module::factory()
• Added Framework_Module::start()
• Added Framework_Module::stop()
• Added Framework_Module::__shutdown()
• Added Framework::stop()
• Added Framework::$module for storing running module instance
• Added Framework::$site for storing running site instance
• Added Framework_User
• Added Framework_User::singleton()
• Added Framework_Object_Web
• Added Framework_Site_Common::getUriPath()
• Added check in Framework_Presenter_Smarty::__construct() to check for writeable cache/compile dirs
• Added support for custom Framework_User classes
• Assign Framework::$site to Smarty templates in Framework_Presenter_Smarty
• Deprecated FRAMEWORK_LOG_FILE in Framework_Config.php
• Deprecated FRAMEWORK_LOG_DSN in Framework_Config.php
• Deprecated FRAMEWORK_USER_TABLE in Framework_User
• Deprecated FRAMEWORK_USER_PRIMARY_KEY in Framework_User
• Deprecated FRAMEWORK_USER_DEFAULT_USER in Framework_User

Download Framework 0.1.0

Per Andrew’s comments from my last post I’ve gone ahead and added extra checking on the weight provided when adding a node. DB_Virtual will now throw an error if you provide a weight equal to or less than zero.

1. Fixed a possible divide by zero error
2. Added check for weights less than zero

Download DB_Virtual 0.0.5

I’ve been working on ways to balance database traffic amongst multiple servers for about a week now. Initially, I had created a DB driver class that extended from DB_mysql, but opted for a cleaner approach using the decorator pattern.

Essentially, DB_Virtual allows you to connect to N database servers with one of them acting as the master. 100% of all manipulation queries (ie. DELETE, INSERT, etc.) are sent to the master nodes while SELECT queries are balanced amongst the remaining nodes using a weighted round robin approach.

The pros of this are obvious, you can take your database traffic and with little effort balance traffic amongst your database nodes. The con is that you have X * N connections per request where N is the number of database nodes and X is the number of databases you connect to.

<?php

require_once 'DB/Virtual.php';

$db = new DB_Virtual();

// Attach a master (you MUST do this first)
$result = $db->attachMaster('mysql://root@192.168.10.25/enotes_com',50);
if (PEAR::isError($result)) {
    die($result->getMessage()."n");
} 

// Attach a node (do this for however many nodes you have)
$result = $db->attachNode('mysql://root@192.168.10.10/enotes_com',50);
if (PEAR::isError($result)) {
    die($result->getMessage()."n");
} 

// Depending on the query DB_Virtual will either propagate the call to all
// nodes or send it to the master.
$db->setFetchMode(DB_FETCHMODE_ASSOC);

// Use DB_Virtual just as you would PEAR DB
$result = $db->query("SELECT * FROM tbl");
if (!PEAR::isError($result)) {
    while ($row = $result->fetchRow()) {
        print_r($row);
    }
}

?>

The best part is DB_Virtual is 100% compatible with PEAR’s DB package so there’s no reason to go around changing all of your code as it should work automagically through the wonders of PHP5’s overloading mechanism.

Download DB_Virtual 0.0.4

If you use the PEAR package Net_Curl you might want to take a look at the numerous patches and bug fixes I recently put together. Hopefully, these will be rolled into a release soon.