Extension:Cargo/FAQ

Why does Cargo exist?

Semantic MediaWiki and its related extensions already offer most of the functionality of Cargo, which raises the obvious question of why Cargo was created in the first place. This is addressed in the page Cargo and Semantic MediaWiki.

It should be noted that there is nothing inherently wrong with Semantic MediaWiki; it's a fantastic extension, and any wiki that uses it is significantly better off than a wiki just running core MediaWiki.

Why is it called "Cargo"?

"Cargo" was chosen because it fit a variety of criteria: short and (hopefully) memorable, not a name already in use within MediaWiki or significantly in the larger software world, and reflecting something about data storage.

This extension is also somewhat named after the author's daughter, who as a baby was referred to by several people as "precious cargo".

Is Cargo secure?

Given that Cargo makes what are essentially direct SQL calls into the database, security is naturally a concern. There are two main potential security issues:

• Users using Cargo to view non-Cargo database tables
• Users accidentally or maliciously modifying or deleting non-Cargo database tables.

For both concerns, the design of Cargo is meant to avoid such a possibility. Cargo does a lot of validation of queries to avoid things like SQL injection. And Cargo accesses the database with a built-in prefix, "cargo__", which means that if it goes to read from, write to or delete a table called "ABC", the MediaWiki code will translate that into a table name called "cargo__ABC". In that way, only tables with the "cargo__" prefix can be read or modified by the Cargo code.

Finally, you can configure Cargo to store its data in a separate database entirely from the one used by MediaWiki, just by setting some LocalSettings.php variables (see Installation). This will establish a clear wall between the Cargo data and the rest of the MediaWiki data.

How is Cargo's performance?

Generally, Cargo's performance seems to be good. Various tests of Cargo's performance have been run; see the performance testing page. Cargo queries have been found to run 30-50% faster than equivalent queries in Semantic MediaWiki. One wiki farm, Gamepedia, found that switching from SMW to Cargo significantly reduced server crashes.

There is the possibility that users, maliciously or otherwise, could use Cargo to construct queries that slow down or even crash the database or server. Cargo tries to prevent this by requiring a "join" condition for every database table mentioned in the query, as well as by indexing its DB fields (although perhaps more should be done here).

Additionally, as above, you can always create a separate Cargo database, potentially even on another server, to minimize the impact that Cargo queries would have on the main MediaWiki database or server.

Why doesn't data I have just added show up in queries?

This same issue exists for Semantic MediaWiki, and the solutions for it are essentially the same.

There is sometimes a lag between when Cargo data gets created or modified, and when that new data shows up in queries; that is due to MediaWiki's own page caching. You do not need to re-save the page containing the query in order to see the new data — instead, you can refresh the query just by doing a MediaWiki refresh/purge on the page. You can do that by going to the URL that ends with "&action=purge" for that page. If you are an administrator, you should see a tab on each page, "Purge cache", that goes to "action=purge". Or you can simply wait — cached pages usually get refreshed within 24 hours or less.

If there are certain wiki pages that you want to never be cached, you can install the MagicNoCache extension, and add the string "__NOCACHE__" to anywhere within those pages.

Finally, if you run a small- or medium-sized wiki, you can simply disable MediaWiki page caching altogether, which probably will not have a huge impact on performance. This can be done in one easy step.

Why doesn't my API query with _pageName as a field work?

You aren't allowed to have a field name alias in an API query that starts with an underscore. Try querying _pageName=Page (or the alias of your choice) instead.