Philippe Vanhaesendonck wrote:
> Reini,
> The ADOdb/Oracle backend is working more or less (still have to fix a
> couple of things), but I am not too happy with the current state...
Yes, me too... :)
> So here are a couple of questions about WikiDB and backends:
>
> 1. Table names / database objects: where do the 'abstraction' happens?
> I was initially thinking that the backends were responsible for the
> 'physical' implementation -- including table naming (e.g. _table_names
> hash), but it looks it is not the case, since we find back table names
> in WikiDB.php.
> Given the fact that WikiDB is not using the same names ('links' io
> 'link') and does not uses prefixes, I am missing some 'translation
> table' here...
The backend constructor holds the hash $this->_table_names, which is
extracted for each method. Certain extensions (session, rating, dbprefs,
...) add to this hash.
The "links" in WikiDB which you spotted is a typo. But it was for the
intermediate upgrade step from locking to transactions.
I added the list of tables which need to be locked to the backend method
of _lock_tables, so that the application lock can be generated (simply
concat the tablenames).
I know, this is a bad hack, but better than locking all tables, and
needed till we will have converted it to transactions where we really
need them. At the beginning of each db transaction, and not within each
and every submethod.
I wanted to have this finished for the 1.4.0 release.
> 2. locking mechanism
> This is looking a bit weird to me: we are locking all over the place:
> WikiDB, backends, inside and outside transactions, ...
> Is there a rationale behind this?
> It does not look very compatible with a transactional DBMS which does
> not hold locks longer than a transaction (and cannot unlock without
> ending the transaction). The notion of transaction and locking are
> tighly bound.
I know. Sigh.
The first version was for mysql only, which needed locking ALL tables
(for MyISAM). A complete mess.
I tried to loose the locking a bit by slowly converting to use
transactions and application locks instead, but this conversion is not
yet finished. So better DBMS still have to suffer from the mysql
architectural decisions.
For ADODB it's a bit better, since I rewrote it for 1.3.10 completely.
But we still have the mess from old WikiDB.php and it's _lock_tables()
calls throughout all nested methods. All these have to be converted to
transactions, and mysql as stupid case has to translate
BeginTransaction() to lock_tables.
> 3. ADOdb generic backend
> We do have a lot of mysql specifics testing in there...
> eg:
> if ((substr($dbh->databaseType,0,5) == 'mysql')....
>
> Shouldn't we try to have a backend which is really generic, and have all
> the database specifics in the ADODB_<db>.php subclass?
>
> Current situation is relatively messy (no offense -- just my impressions)
That's absolutely right. For simplicity I left it as is, but the
dynamic $backend->_dbh->databaseType checks should be moved into the db
specific backends. mysqli and mysqlt should be tested, ...
The real problem is mysql, which is a mess.
ADODB is also a mess, as you can see with the fetchMode hack.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
|
