Am 04.09.2014 20:01, schrieb Jeroen De Dauw:
Hey,
* Symphony
The Symfony Console component, no the Symfony framework.
sloccount gives me:
Total Physical Source Lines of Code (SLOC) = 10,570
That's a lot for a little bit of conveniance when deailing with command line
arguments...
1) Split the
command line interface into a separate component (WQE-CLI
perhaps) that would not
be deployed.
This is easy to do, though will be less convenient for users of those scripts.
What exactly is the scope and purpose of the cli interface, anyway? You can use
it to re-generate the tables, and populate them, right? The two or three main
use cases could easily be re-implemented without symfony, don't you think?
2) Go back to
using MediaWiki's DB abstraction for running queries.
We cannot directly use it without making QueryEngine depend on MediaWiki, and
without losing the ability to run the tests with an in-memory SQLite database.
Luckily we can easily switch back to using the interface originally written for
this task:
https://github.com/wmde/WikibaseDatabase/blob/master/src/QueryInterface/Que…
Why would we not be able to use sqlite? For queries, MW's abstraction layer
should handle that just fine...
The dependency on MediaWiki could be optional: we could have implementations of
the query interface based on MW's DatabaseBase, and in addition, dbal. So you'd
need to have one of the two, but nither would be a hard dependency.
3) For
generating DB tables (aka schema creation), we create a separate component
The schema definition code should not be moved into it's own component. It
belongs very close to the code using the schema.
True. Schema *generation* might, though. But I agree that it's not nice to split
this.
So I don't see a sane way of
getting rid of all code that depends on DBAL in a sane way. We could create our
own implementation of this functionality again, though I do not consider that to
be a sane approach.
indeed
The code in question will not be executed on the WMF
cluster
though. And if you want to be really paranoid about it, you can just delete dbal
from the build before it goes onto the cluster, and be sure it is indeed not
executed.
How about making an optional dependency: if you install dbal, you can generate
new schema creation scripts based on your setup (may include extra tables for
additional value types or whatever). If you don't, you only get the
pre-generated standard files. Would that work?
-- daniel
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.