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 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 baby daughter, who has been 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 deleting non-Cargo database tables.

For both concerns, the design of Cargo is meant to avoid such a possibility. Cargo does not directly make SQL calls, but rather uses MediaWiki's database-access code to interface with the database, which is meant 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 "Configuration", above). This will establish a clear wall between the Cargo data and the rest of the MediaWiki data.

How is Cargo's performance?
No rigorous testing has been done yet, but for standard queries, the performance seems to be quite good.

There is the possibility that users, maliciously or otherwise, could use #cargo_query 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 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. If you are a MediaWiki administrator, you can do this by simply hitting the "purge cache" tab for the page. If you are not an administrator, going to the URL that ends with "&action=purge" for that page will have the same effect. 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.