After extensive testing and rewriting, I’ve broken out of my former mold, and have taken dbshim out of the works, instead, I’m now using my rewritten rollatorDB.

While doing so, I re-implemented my RSS feeds, cleaning up quite a bit of the cruft in that code while extending it a bit more.

You, the end user can now decide how many articles you want to view, and if you want to view the entire article, or only a section. By appending “fullcontent” unto your query, it will display the full article within the feed. “num=xx” will allow you to view the last xx entries, and last, but not least, “length=xx” will break the feed at the specified number, by default, 250 characters into the article. Keep in mind that “fullcontent” is a boolean, and will override length.

So, the query of:

http://www.holwegner.com/rss.php?fullcontent&num=30

will display the entire article for the last 30 entries, whereas,

http://www.holwegner.com/rss.php?num=10&length=74

will display the last 10 articles, cutting off at the 74th character, good enough for a brief synopsis (usually).

Working with PHP classes is quite a bit different than just creating, and calling subroutines, but it is a rather pleasant abstraction – with my rollatorDB::fetchAssoc, and rollatorDB::fetchAssocRow making life much easier than manually stepping through everything with the archic ways of old, which looked similar to:

$result = my_db_query(“SELECT …”); while (list($myID, $myTitle, $myContents, $entryDate, $lastModDate, $entryType) = mydb_fetch_row($result)) {; ... do stuff… }

It’s now as simple as:

$myVariable = $rollatorDBvar->fetchAssocRow(“SELECT ….”) ... dostuff…

Of course, due to this the flow has slightly changed, but it’s for the better since I have all of my data in a local array, and all of the DB work is done by the time I’m parsing it, making for a much faster system!

I must admit to having been quite busy over the last few weeks, with my relocation to my old state of Nevada, and finishing up my contracts..

I’ve managed to get rid of the last bit of bloat which was my external RSS parser. I’ve written a slightly odd code snippit which uses PHP’s (now) native XML routines to parse an RSS feed. It will stuff an associative array with variable data it accumulates.

No caching, hence, no ‘if changed’ resources – as of yet. Regardless, it works quite well, and is under 3k.

Since the rewrite of rollator into a full-fledged OOP structure, I’ve been asking myself, as well as been queried a few times by curious parties: “How will it work?”

I’ve tried to make it as painless as possible. If you note my prior post, you’ll see that all DB specific queries have been made abstract, so you need not know what the DB is. You are, however, required to format proper SQL queries. ;)

Here’s how it might look:

$myDB =& new rollatorDB(”$myHost”, ”$myUser”, ”$myPass”, ”$myName”, ”$mydbType”);
$array = $myDB->fetchAssoc(‘SELECT id, content FROM mycontentdb LIMIT 1’);
echo “fetchAssoc ”;
print_r($array);

$rowArray = $myDB->fetchAssocRow(‘SELECT urltitle, fullurl FROM urldb LIMIT 1’);
echo “fetchAssocRow ”;
print_r($rowArray);

$myDB->dbClose();
?>

It’s pretty simple, no? Sure, it can use a bit of further abstraction, but for the most part, the logic’s entirely written. It works with single array and row queries, raw queries, and as demonstrated above, it will fetch all associative fields, either in an array, or in the fairy common ‘row’ format.

The difference lies in that arrays return the type searched for with the name, and the row merely returns the data. For our test sample, let us assume the following is returned:

fetchAssoc Array ( [0] => Array ( [id] => 1 [content] => Hey this is my content. Is it not great? I think it is so! Please, send me much money so I might make such wonderful content for you! )

)
fetchAssocRow Array
( [0] => Array ( [0] => Sweet Cuppin Cakes [1] => http://www.homestarrunner.com/main18.html )

)

You’ll find that the array query returns the variable name as the identifier of the data, whereas the row merely returns the data.

Personally, I like the ability to discern the data type more with the array, but if one is entirely sure that they will continue to use the same exact format and return their data, er, proper, the row lookup does have a trivial amount of speed increase.

Of course, to fully see what rollatorDB supports, you might just want to see the source.

With the maturing of PHP, and the final inclusion of deconstructors in the up and coming PHP 5, I’ve opted to finally get rid of some of my old cruft, and start making it OOP.

This code is not the world’s best example, but one of the first things I’ve done is rewritten the SQL database shim; this tricky little bugger allows me to account for the differences in SQL layers within PHP. Currently, it supports MySQL and PostgreSQL (it supported DBX, but I’m going to rewrite it for SQLite shortly).

What’s the difference? Quite a bit. The abstraction, with a bit of logic, allows for several simutaneous connections without fear of ‘treading on toes’ as dbshim was initally written to manage the database connection IDs by itself, however, this logic was not introduced until the move to OOP.

Find below a rather icky (elder) version from my intial revisions of dbshim:

function my_db_connect() { global $mysqlindex, $mydbhost, $mydbusername, $mydbpassword, $mydbname, $mydbtype; if ($mydbtype "mysql") { $mysqlindex = mysql_connect($dbhost, $dbuser, $dbpass) or die("Unable to connect to server."); mysql_select_db($dbname) or die("Unable to select database."); } elseif ($mydbtype “pgsql”) { $mysqlindex = pg_connect(“host=$dbhost dbname=$dbname user=$dbuser password=$dbpass”); } elseif ($dbtype == “dbx”) { // eventually, we’ll have to do SOMETHING, I think } }

This would be called by:

my_db_connect();

It would happily usurp global variables, which were only available to dbshim, but were quite bad, regardless.

Rewritten in OOP, it looks like this: class rollatorDB { function rollatorDB($dbhost, $dbuser, $dbpass, $dbname, $dbtype) { $this->mydbtype = $dbtype; switch ($this->mydbtype) { case “mysql”: $this->mysqlindex = mysql_connect($dbhost, $dbuser, $dbpass) or $this->error(“Unable to connect to server.”); mysql_select_db($dbname, $this->mysqlindex) or $this->error(“Unable to select database.”); break; case “pgsql”: $this->mysqlindex = pg_connect(“host=$dbhost dbname=$dbname user=$dbuser password=$dbpass”); break; default: $this->error(“Unable to connect: Unsupported DBType given!”); } } /* Other functions follow… */ }

As you can see, I switched to, er, switch statements, and have added an internal error system to this shim, so it won’t explictly call functions outside of itself, which is considered to be bad.

The new functionale is called as such:

require ‘rollatorDB.php’;

$myDB = new rollatorDB(”$mydbhost”, ”$mydbuser”, ”$mydbpass”, ”$mydbname”, ”$mydbtype”);

It’s different. I’ll give it that.

Where I used to use $result = my_db_query(“SELECT foo FROM bar WHERE quux=’baz’”); , I’ll now be using $result = $myDB->my_db_query(“SELECT foo FROM bar WHERE quux=’baz’”); Update: Now, well, I’ll actually be using $result = $myDB->dbQuery(“SELECT foo FROM bar WHERE quux=’baz’”);

It’s nice, since I can have several instances, if need be, with no global variable pollution.

The code is getting tighter, despite the silliness above; and by using switch statements, it’s not only more legible, but fairly trivial to add support for future databases.

Update: Since taking the plunge, I’ve rewritten the whole thing, as you can see for yourself, and even converted the elder style underscores to studlyCaps. ;)

It’s been coming down the pike.

I’ve been well aware of how my tools have become widely utilized. This has become a bit of a problem, as my excellent virtualhost provider allows a total of five gigs of transfer a month. Not so bad?

Well, since several of my tools have hit VersionTracker, I’ve been doing an average of a gig’s worth of traffic a day. This, as they say in the business, is not good.

I had to find a way to distribute this influx.

I run several services, as well as my personal website – not only do they have quite a bit of space by comparison (the majority of my traffic and storage there is SQL based) – they rarely come near their bandwidth utilization.

I hacked up support in my filemanager to allow for mirror sites to be listed in my global configuration, then opted to expand it after I had the initial frameworks laid out.

My initial revision allowed for a single mirror – it would continue to update my local download counter (as it should), for any file downloaded, then “hand off” the request to the sister site.

In an effort to increase my functionale, I then created a pseudo-random ‘site chooser’, entirely transparent to the client, which makes an educated guess as to which of my mirrors to use.

Hopefully this will save me from paying a fortune for my bandwidth, and be able to provide end users with the tools they seek!