mwsql provides utilities for working with Wikimedia SQL dump files.
It supports Python 3.9 and later versions.
mwsql abstracts the messiness of working with SQL dump files.
Each Wikimedia SQL dump file contains one database table.
The most common use case for mwsql is to convert this table into a more user-friendly Python Dump class instance.
This lets you access the table's metadata (db names, field names, data types, etc.) as attributes, and its content – the table rows – as a generator, which enables processing of larger-than-memory datasets due to the inherent lazy/delayed execution of Python generators.
mwsql also provides a method to convert SQL dump files into CSV.
You can find more information on how to use mwsql in the usage examples.
You can install mwsql with pip:
$ pip install mwsql>>> from mwsql import Dump
>>> dump = Dump.from_file('simplewiki-latest-change_tag_def.sql.gz')
>>> dump.head(5)
['ctd_id', 'ctd_name', 'ctd_user_defined', 'ctd_count']
['1', 'mw-replace', '0', '10453']
['2', 'visualeditor', '0', '309141']
['3', 'mw-undo', '0', '59767']
['4', 'mw-rollback', '0', '71585']
['5', 'mobile edit', '0', '234682']
>>> dump.dtypes
{'ctd_id': int, 'ctd_name': str, 'ctd_user_defined': int, 'ctd_count': int}
>>> rows = dump.rows(convert_dtypes=True)
>>> next(rows)
[1, 'mw-replace', 0, 10453]Wikimedia SQL dumps use utf-8 encoding.
Unfortunately, some fields can contain non-recognized characters, raising an encoding error when attempting to parse the dump file.
If this happens while reading in the file, it's recommended to try again using a different encoding. latin-1 will sometimes solve the problem; if not, you're encouraged to try with other encodings.
If iterating over the rows throws an encoding error, you can try changing the encoding.
In this case, you don't need to recreate the dump – just pass in a new encoding via the dump.encoding attribute.
Some Wikimedia SQL dumps contain string-type fields that are sometimes not correctly parsed, resulting in fields being split up into several parts. This is more likely to happen when parsing dumps containing file names from Wikimedia Commons or containing external links with many query parameters. If you're parsing any of the other dumps, you're unlikely to run into this issue.
In most cases, this issue affects a relatively very small proportion of the total rows parsed.
For instance, Wikimedia Commons page dump contains approximately 99 million entries, out of which ~13.000 are incorrectly parsed.
Wikimedia Commons page links on the other hand, contains ~760M records, and only 20 are wrongly parsed.
This issue is most commonly caused by the parser mistaking a single quote (or apostrophe, as they're identical) within a string for the single quote that marks the end of said string. There's currently no known workaround other than manually removing the rows that contain more fields than expected, or if they are relatively few, manually merging the split fields.
Future versions of mwsql will improve the parser to correctly identify when single quotes should be treated as string delimiters and when they should be escaped. For now, it's essential to be aware that this problem exists.
mwsql is released under the GPLv3.
You can find the complete documentation at Read the Docs. If you run into bugs, you can file them in our issue tracker.
Have ideas on how to make mwsql better?
Contributions are most welcome – we have put together a guide on how to get started.