Aryeh Gregor escribió:
> On Sat, Dec 27, 2008 at 1:23 AM, Jesús Quiroga <[email protected]> wrote:
>
>> 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' and
'wildly successful'.
>> The 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
(https://wiki.toolserver.org/view/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
'official'.
Best regards.
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
