17 October, 2006

miscellany: more stupid database workaround ideas...

Don't yet know if this is feasible, but the bot could keep its own database separate from the one on the site.

Once the bot connects, check to see if the bot's members db matches the members db stored on the site by counting rows. If not, then upload the bot's members db changelog to the bot, and run the changelog through SQLite on the site, or download the site's changelog and process as needed to the local bot. Set up something like a cronjob to do the check/update automatically at a given interval, or on demand by admins.

Then, any queries run on the site will be performed against the db stored on the site, and any queries run on the bot will be performed against the bot local db. So changes won't necessarily be instantaneous between the various bots and the website, but it should be good enough.

Could get really ugly and clunky, but it's a cheapass workaround to having to perform actual db synchronization. Bound to be a problem with a system with a large number of concurrent users, but there isn't any fear of that.

4 Comments:

Anonymous Anonymous said...

Wouldn't a row check only reveal that the db holds more or less members? So that a member changing depts wouldn't get caught... or if one ducked out and one ducked in?

You gotta see this CSS I picked up. It's to customize your MySpace page... Either it has some really stupid stuff or some really clever stuff. I think I'll post it to ds:s later.

12:24 PM  
Blogger elegiac said...

Current thinking is writing any SQL changes to a local file. Comparing the bot_changelog file to the changelog file stored on the site. If there's a difference, download/upload the file, then process the SQL.

It's probably not going to happen at this point-- got a bit derailed temporarily with the idea of starting a bot from chunks of different bots, and then incorporating some of the plugin stuff that's already done.

Assuming I can get the damn thing to do more than just log in, I'll get back to the DB stuff.

(Though my more masochistic side decided it might be fun to try and do something really ridiculous- store the website data in a MySQL db, the backup data in a PostgreSQL db, and the local data in an SQLite db.

Should make for a dumbass amount of converting back and forth, or require the use of a database abstraction layer.)

12:18 AM  
Anonymous Anonymous said...

I'm not sure about v4.x but v5.x has a PEAR called DB that standardizes and to a certain degree simplifies dealing with multiple database programs. From what I've read, you don't even have to know/care what db you are using.

require db.php;

Oh and the only thing I can think of that would be an issue with the changelog file is security related. Anyone who can guess the file name on the web server can view the file, I think. Otherwise it's pretty brilliant.

3:30 PM  
Blogger elegiac said...

I'm aware of a few of the database abstraction layers-- it's more of a challenge to have to do it as I go, though. No need to have it completely handed to me, when I can make my own buggy interpretation instead.

(DB *does* work with PHP 4. At least it says it does.)

As far as the changelog, I'd set it into an FTP accessible area. Set up a username/pass for the bot, and have it log in and check the file. Or, set up .htaccess to prevent it showing up. Or both. Probably both. :D

12:11 AM  

Post a Comment

<< Home