Aryeh Gregor escribió:
On Sat, Dec 27, 2008 at 1:23 AM, Jesús Quiroga
The second way to access the data store that is
usually considered is
the 'indirect' one:
[wiki] <--- wikiDataL ---> [polyglot translator]
[polyglot translator] <--- mysDataL ---> [mysql]
[polyglot translator] <--- posDataL ---> [postgresql]
[polyglot translator] <--- db2DataL ---> [db2]
Here, wikiDataL means 'some relational data definition and manipulation
language suitable for use by the wiki'.
This is what we currently use, and I don't think we're going to
seriously consider changing it without some very compelling arguments
being presented. Incremental improvements to our current way of doing
things (cutting back on raw queries, moving MySQL-specific stuff from
Database to DatabaseMySql, defining more clearly what Database methods
mean and avoiding undefined behavior) seem entirely sufficient to
allow support for any number of additional database backends.
I understand you mean the indirect way is the 'official' way now, and
that's is quite understandable. However, there are parts that 'lag
behind' because they still use the obsolete direct way, and at the
same time there are wikiNeedL phrases already in some other places, so I
see that MediaWiki uses parts of all three. Usually, transitions from
one way to other happen slowly, and feel like gentle evolutions,
either towards improvement or towards degradation.
I agree, the indirect way can support many backends, no question. In any
case, it will be a comparison between 'good' and 'better', or to be
clearer, between 'cheap' and 'cheaper', or perhaps 'successful'
differences between wikiDataL and wikiNeedL are mainly these:
- wikiNeedL would contain just enough wiki concepts to express the
wiki's needs, so it's effectively confined to that domain. wikiDataL
belongs to the relational data model domain, which is quite different.
- in general, wikiNeedL would have different semantics than the
dialects understood by the databases, so the translation step becomes
more like interpretation, rather than just syntactic transformations.
wikiDataL usually has the same semantics than the dialects.
- wikiNeedL would contain just enough concepts to satisfy current
needs, and will be open to extension. wikiDataL aims to be
general-purpose and to fulfill current and future needs.
In practice, wikiNeedL would be drastically more complicated, if I
understand you correctly. Its basic semantic units would be things
like articles, users, revisions, etc., instead of rows, columns, and
tables. We *have* a wikiNeedL, in fact: it's called "calling the
appropriate Article method" or whatever. Most code doesn't have to
manually do queries. Further abstraction of the database queries
would be possible, but I question its usefulness
I agree completely, some wikiNeedL is already in there, and it's
implemented using method calls and their arguments, which is just fine
and it works. I'm confident you'll see it's not that complicated.
For example, I found these in Article.php, method updateRedirectOn():
$dbw->replace( 'redirect', array( 'rd_from' ), $set, __METHOD__ );
$dbw->delete( 'redirect', $where, __METHOD__);
These I consider wikiNeedL phrases, and they're (almost) perfect. Some
helper agent is located and told about some need that ought to be
fulfilled, and what is needed is expressed clearly using wiki
concepts. No details about how to do it are included, except for that
string 'rd_from' which seems to be a column name in some relational
schema, and that would be forbidden in wikiNeedL proper.
Of course, simple expressions are easier to manage, even trivially so,
but they are good examples of the ideas I described.
Another example, consider the query service
), where someone with a
need to access the data store manages to do so by delegation, expressing
the need using wiki concepts. Of course, they are humans, but the model
is the same.
The usefulness of the interpreted way can be compellingly argued, and I
plan to do so in a separate message. Finally, to get the full benefits
of wikiNeedL, if it is deemed to be a good idea, I believe the first
step should be to begin to steer its evolution in a top-down fashion, to
analyze what is there, to bring it forward, and to make it more