-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Parker writes:
>I'd love to see some sort of more generalized SQL interface that can
>be used by many different "subsystems" can use for their data
>storage. For instance, the hashcash stuff Justin just added. It uses
>a DB_File to store the double spend data. It would have been great if
>he could have made some sort of API call to store the data, hiding the
>storage details. With the addition of the AWL and Bayes SQL storage
>backends there would be three similar but slightly different methods
>for talking to a SQL database, I'm gonna try and unify at least the
>AWL and Bayes SQL stuffs as time permits. Admittedly I don't have a
>whole lot of experience with the SQLConf stuff. I've only set it up
>once for a short while and haven't really messed with it much since.
FWIW -- one problem with unifying systems through 1 access method
is that they have different models for rw/read-only access:
- AWL: always ties R/W, performs a fast operation, unties quickly
- hashcash: always ties R/W, performs a fast operation, unties quickly
- Bayes: ties R/O 90% of the time for slow operations, ties R/W 10%
for another small set of slow operations
This can complicate matters, and overlooking it would result in more
deadlocks, slowdowns, and missed opportunities for DB writes; which is why
they're using different DB access code.
But an easy way to work around that is to just move all that DB access
code into 1 class like so:
package DBBackendFile
sub tie_awl_rw {...}
sub tie_hashcash_rw {...}
sub tie_bayes_ro {...}
sub tie_bayes_rw {...}
and implement a different DBBackendSQL implementing the same methods.
ie. the actual *use* of the DB is still reflected in the method
names and operation even down to that level.
More fine-grained locking/unlocking methods to support SQL are easy
enough to add after that; we just make them no-ops for the DB_File
backend.
BTW Michael -- yes, I still intend to merge that for 2.70 ;) If it's
good, it'll provide a good start for the SQL work. If it's bad, it can be
ripped to pieces in that process ;) I just want to make sure someone's
willing to take control of the whole SQL side of the code as we
increase its coverage.
- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Exmh CVS
iD8DBQE/30p/QTcbUG5Y7woRAqhrAKCpipj+ldnyZkShgkYz6jSfk5rOkACfdqus
QOsUNkCXjd5HJBU9Z90ZnCI=
=A2FS
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
