Cargo: FAQ

From Gamepedia Help Wiki
Jump to: navigation, search
Prof hydra.svg Adapted from the Cargo extension documentation.

Why does Cargo exist?[edit | edit source]

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.

Why is it called "Cargo"?[edit | edit source]

"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 developer's daughter, who as a baby was referred to by several people as "precious cargo".

Is Cargo secure?[edit | edit source]

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?[edit | edit source]

Generally, Cargo's performance seems to be good. Only one small-scale test of Cargo's performance has been done so far; see the performance testing page. In that test, a query in Cargo ran 50% faster than an equivalent query in Semantic MediaWiki.

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?[edit | edit source]

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.

Help! This page isn't storing data from any table, what's going on?[edit | edit source]

You probably tried to specify unique in one of your fields in one of your tables, and there's a conflict. This may not be your fault, unique parameters can be pretty buggy. Try finding some workaround solution that doesn't require the unique.