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/QueryInterface.php 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. _______________________________________________ Wikidata-tech mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
