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...
- 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?
- 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/Quer...
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.
- 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