[Slashcode-development] Oracle Port Progress, April 19: Inheritance Tax

[Stephen C. <the...@wa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There was a lot of progress today so this is larger than normal.  Not that
anyone would complain about that :)

First and foremost, I've had a chance to really test things out with MySQL, and
it seems to be running properly, even with all the underlying structure
changes.  No errors in the logfile, at least.  I'm now using the MySQL copy to
ensure that Oracle is aligning with it.  The whole system makes more sense to me
now that I can see that some things are being completely left out under Oracle
:)  (More on that later...)

I've been having some crosstalk between MySQL and Oracle methods ever since I
hacked a method in to do some extra transaction initialization commands on
Oracle.  The Oracle method was also attempting to run on MySQL, for no apparent
reason.  I dug up this comment in Slash::Apache::User:

#Ok, this solves the annoying issue of not having true OOP in perl
# You can comment this out if you want if you only use one database type
# long term, it might be nice to create new classes for each slashdb
# object, and set @ISA for each class, or make each other class inherit
# from Slash::DB instead of vice versa ...

Perl's interface inheritance is definitely a "bottom-up" approach along the 
lines of Eiffel, so trying to force the downward inheritance into Slash::DB
itself doesn't work very well.  So today I fixed that, flipping the current
"top-down" model over.  IMO Slash::DB just got a hell of a lot simpler -- all it
does is figures out the correct class name, loads the necessary driver module,
and then blesses the initial hash into that class instead of Slash::DB.  The
onus for proper inheritance is now placed on the database driver module, which
is probably a Good Thing.  I've already patched all the existing drivers and
they work just like they did before.  A few more changes went into 
Slash::Install because it did some rather unorthodox object blessing on itself
that was throwing things off.  In any case, this eliminates a lot of confusion
and chicanery from the structure of the Slash::DB tree.

I've also tightened up Slash::DB::Utility some more, breaking out select
statement generation into an independent function, as well as reusing
some of the sql functions inside the sql functions when possible.  This
eliminates copious amounts of redundancy in the sqlSelect* routines.  MySQL code
continues to work in its original form (I haven't gotten around to modifying any
of it yet), so I'd have to say the extended interface has proven itself clean
and backwards-compatible.

Today I had an epiphany about an even more brilliant idea for SQL
generation.  I think a desirable (not to mention wickedly cool) goal would be to
come up with a database-neutral syntax for defining a query, and then writing
database-specific functions to convert that data into SQL for that 
database.  Instead of coding specific routines for every single database, come
up with one definition in Slash::DB (note that this is a poor and 
quasi-confusing example, but you get the idea):

$db->sqlSelect(
	select => 'col1, col2, col3',
	from => 'table',
	where => {
		col1 => 'foo',
		col2 => 'bar'
	},
	order => 'col1, col2, col3',
	startrow => 5,
	limit => 10
);

And from that generating a query for whatever database one is using.  This would
greatly simplify porting down the road, since the queries would remain constant
- -- all one has to do is write a translator so Slash can speak that database's
language.  (This would also be a nice place to transparently fix up those
renamed columns....) I've been playing around with a subset of this concept at
work, just to ease the pain for everyone around there writing raw Oracle
SQL.  But I didn't think about the application here until this 
evening.  Obviously this is a change for down the road (definitely past 2.0 
release) but it certainly sounds like a plan.  There are a few Perl modules that
do this sort of thing already but I don't find any of them particularly
well-done, so at least to me it would be a from-scratch thing designed for
Slash.

Anyway, enough dreaming, back to stuff that actually exists.

When I got MySQL working I beheld the admin menu for the first time.  Yes, it
didn't show up at all in the Oracle copy, because the Admin plugin's dump script
never ran to load the menus table.  After fixing the plugin file, more problems
ensued there because of Oracle's syntax anality.  There are a number of hacks
both in install-slashsite and Slash::Install for parsing the MySQL dump files so
Oracle will accept them, but I'm not very fond of this kind of hackery.  So I'm
working on a more database-independent (but still ASCII) dump format, so we
don't need a different initialization file for each database flavor.  This is
pretty low priority, though.  My main goal is to offer something that at least
halfway works before this weekend is out.

Another problem is Oracle's magnanimous flaw of treating '' == NULL, which
wouldn't be a problem except that '' is used as the magic "all" value for a
couple tables, like sections and topics.  So I created a method for changing the 
"all" value for those tables.  Still trying to find all the places where it
matters.

Finally, I'm trying to find as many creative ways to offload some of the work
that things like slashd take care of.  Perhaps the biggest and most obvious one
would be changing the newstories table to a materialized view that Oracle itself
would keep updated.  I'm sure as this port gets deeper I'll find other things
that Oracle can work magic on as well.

Things are moving along well.  Stay tuned.

- -- 
Stephen Clouse <the...@wa...>
warpcore.org Founder, Chief Megalomaniac, and Evil Overlord

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBOt/F6d1EXk7JbKbMEQKFjwCgwKmVjPyusbtynykpCUB3Ucdi8BUAnRO9
CNq+VoLDLtgk3bb/2onpRnJz
=x3iC
-----END PGP SIGNATURE-----