Engines

An adapter is a claim about somebody else’s database: that WordPress keeps a post’s state in post_status, that PrestaShop stopped keeping a variant’s stock in product_attribute at 8.0. The table below says which engines i2b maps and, for each, whether that claim has been checked against the engine vendor’s own published schema.

What i2b maps

10 of 13 have been checked this way so far. “Checked” means the adapter’s table and column names, and the demo fixtures, are asserted against a copy of the vendor’s own schema kept in the repository with the URL it came from and a SHA-256 of the file. Run for the first time on 14 October 2026 against the schemas six vendors publish, it found four defects in four engines. One lost data: PrestaShop moved a variant’s stock out of product_attribute at 8.0, so every variant of an 8.x shop arrived with its stock empty. One sent a whole database to the wrong adapter: Drupal 9 and Drupal 10 were being read by the Drupal 7 one. The other two were the opposite mistake — columns reported as lost that the engine no longer has, in Joomla and in Shopware.

Three engines publish no schema at all — they declare their tables in code, or ship an installer that writes data and structure together — so on 20 and 21 October each was installed by its own installer in a throwaway container, filled through its own interface, and dumped. That found four more: the Drupal 7 adapter did not know Drupal’s own caches, so ten of them arrived in the loss report as losses; OpenCart 4 moved an address’s destination out of seo_url.query, so every product’s address arrived empty on a 4.x shop; osCommerce keeps the date an account was made in customers_info and the adapter read it from a column that does not exist; and row counts were read from the dump by counting statements rather than rows, so every database a customer’s own tools produced was measured as having one row per table — the number that decides the size band of an estimate.

The three not checked are checked differently or not yet. Amazon and Shopify are not databases: they are the export files those services hand you, and what plays the part of a schema is the column headings of the file. CS-Cart is closed source — there is no published schema and no image to install — so it waits for a real dump from a shop.

Recognised, not mapped

i2b can tell these apart when it reads a dump and has no adapter for them. It says what it found and does not claim to carry it — with the reason, which is the useful part.

• MediaWikiA MediaWiki page does not contain its own text. The text is two indirections away — the page points at a revision, the revision at a content record, and only that names the row the words are in — and which of a page’s many revisions is the current one is a third lookup. It is entirely doable and it is not a table of mappings, so it goes to the bespoke engagement rather than to a button.

Demo databases

Every one of these opens in the workbench without signing in and without a database of your own. They are real exports with the personal data taken out; every address in them is at example.com, which is reserved and cannot belong to anybody.

• A WooCommerce shopProducts, orders and customers spread across WordPress tables that were never designed to hold them — the case the whole product exists for.
• An OpenCart shopThe same shop in a system that models it properly, so the comparison shows what changes when the shape of the data is different.
• A PrestaShop shopA shop in two languages, where the translatable text lives beside each row rather than in it — so the report has something to say about what a second language costs.
• An osCommerce shopA shop from the 2000s, still running. Its order lines carry the prices and names as they were at the time of sale, and its totals are rows of text rather than numbers.
• A CS-Cart shopA shop where one product has several correct prices, one per customer group — so the report shows what tiered pricing costs to move.
• A Shopware 6 shopA modern shop that keeps its prices as JSON, gross and net per currency. Everything else moves; the prices are the decision somebody has to make.
• A Joomla siteNot a shop. Articles, categories and accounts — and articles split into two halves that no mapping can rejoin on its own.
• A Drupal 7 siteA site whose content is not in its content table. Every body lives in a shared field table alongside every other entity’s, which is what makes Drupal hard to leave by hand.
• A Drupal 10 siteThe only one of these that is not generated: a real Drupal 10, installed and filled through Drupal’s own API and dumped. Its content is spread over an entity table, a field-data table and one table per field — and its roles are configuration rather than rows, so the membership moves and the role’s name does not.
• A Magento 2 shopA shop whose catalogue is not in its catalogue table. Every name, price and description lives in one of five tables addressed by a number, and only a dictionary knows what the number means — the shape this product refused for months.
• A Shopify shopA shop with no database at all — three CSV exports out of an admin screen, flattened one row per variant. It shows what a hosted shop costs to leave, and what its export simply does not contain.
• An Amazon catalogueNo database and no shop of your own — one flat file, tab-separated, with its column names in the third row and every variant sharing the file with its parent. The format most likely to already be on somebody’s disk.
• A phpBB message boardNeither a shop nor a CMS: boards, topics and posts. It is here to show the canonical model is a general vocabulary rather than an e-commerce one.