Extension talk:Cargo

Referata
I've read about this new extension on mediawiki-l. Thanks for working on it, I'm impressed. I've read the FAQ item about performance and I wonder if you already have enough data to prefer Cargo on some of your wikis out of performance concerns, or whether you'd need some testing.

In particular, as our generous host for http://wikipapers.referata.com/, you just have to ask and I'll do anything possible to migrate. Especially if it reduces hosting costs/effort for you. --Nemo 01:09, 17 January 2015 (UTC)


 * I'm glad you think it's interesting! I have no performance data on Cargo yet. I didn't understand the second part - are you asking about having Cargo on Referata, or something else? Yaron Koren (talk) 23:45, 18 January 2015 (UTC)


 * Yes, I'm asking about Cargo on Referata. If switching to this extension makes your job of running Referata wikis easier, I'd feel obliged to help. --Nemo 23:51, 18 January 2015 (UTC)


 * Oh, I see. I do plan to install Cargo on Referata, though it wouldn't require any switching - just adding the additional extension. I will probably do that in the next few weeks. Thanks for your offer to help. Yaron Koren (talk) 00:55, 19 January 2015 (UTC)

Compatibility with SMW
Hi Yaron

Will future versions of SF support SMW as well as Cargo or will new versions of SF only support Cargo?

Many thanks

Duncan (17 Jan 2015)


 * I have no plans to drop support for SMW in SF. Yaron Koren (talk) 23:46, 18 January 2015 (UTC)

Not working
I am basically c/p the code from the example pages and change the references to the properties, but I fail to get it going. I always get the following two errors:
 * storing it:
 * This template defines the table "Name". This table has not been created yet.


 * querying it:
 * Error: no database table exists for "Name".

I do not get it. --Temptuousinsolence (talk) 11:15, 20 January 2015 (UTC)


 * You're just missing one step: in the template page, you need to select the "Recreate data" tab, then press the button. That should be explained better in the documentation. Yaron Koren (talk) 13:55, 20 January 2015 (UTC)

Error on Special:ViewData
I have a fresh MW+Cargo installation on localhost. I proceded thru the Quick-Start-Tutorial. Everything seems fine. Tables were created. Forms are working, Drilldown is running, too.

But on Special:ViewData I only get the error: "A database query error has occurred. This may indicate a bug in the software."

I have: MediaWiki 1.24.1 PHP 	5.6.3 (apache2handler) MySQL 	5.6.21 Cargo	0.5.1

Any suggestions? Thanks for help!


 * I'm glad that you got everything working! Special:ViewData is, for now, only a "helper" special page - it's used by the interface, but users aren't supposed to go there directly. I should change that page, though, to display a more helpful message if users do go there. Yaron Koren (talk) 14:50, 21 January 2015 (UTC)

Error after creating Cargo-Tables and View Table
After creating a template and creating corresponding Cargo-Tables (everthing fine till this step) I clicked the "view Tabele"-Link and got this Error: A PHP-Warning Notice: nserialize: Error at offset 594 of 600 bytes in _MYPATH_/CargoTableSchema.php on line 17 and one the page itself this Error: Internal error [e39d5d76] 2015-01-21 13:29:18: Fatal exception of type MWException


 * That sounds bad. (I assume the notice message was for "unserialize", not "nserialize".) I'm guessing that this is a character-encoding issue in some way. If possible, could you add this line right above line 17 of CargoTableSchema.php:

print $dbString;


 * ...and let me know what it prints out? Yaron Koren (talk) 15:09, 21 January 2015 (UTC)


 * Thanks for the fast answer. Although I have a German-Wiki and tables I tried to avoid wired letters. My wiki is about US-Military-Trials after WW II... Here is the printout:

a:11:{s:10:"Angeklagte";a:3: {s:4:"type";s:4:"Page";s:6:"isList";b:1;s:9:"delimiter";s:1:",";}s:6:"Zeugen";a:2:{s:4:"type";s:4:"Page";s:6:"isList";b:1;}s:7:"Richter";a:3: {s:4:"type";s:4:"Page";s:6:"isList";b:1;s:9:"delimiter";s:1:",";}s:11:"Verteidiger";a:3: {s:4:"type";s:4:"Page";s:6:"isList";b:1;s:9:"delimiter";s:1:",";}s:18:"Staatsanwaltschaft";a:3: {s:4:"type";s:4:"Page";s:6:"isList";b:1;s:9:"delimiter";s:1:",";}s:6:"Beginn";a:1:{s:4:"type";s:4:"Date";}s:4:"Ende";a:1: {s:4:"type";s:4:"Date";}s:16:"AnzahlTodsstrafe";a:1:{s:4:"type";s:7:"Integer";}s:16:"AnzahlAngeklagte";a:1: {s:4:"type";s:7:"Int
 * Maybe my Template is wrong and caused the error?


 * Great, that was very helpful. It turns out that the issue wasn't character encoding, but just that I didn't make the "table_schema" field in the "cargo_tables" database table big enough; sorry about that. I just fixed this problem in the Cargo.sql file. If you know how to modify MySQL tables (directly or via phpMyAdmin or such), if you just make that change, then re-save that template and recreate its data, the problem should go away. Yaron Koren (talk) 17:13, 21 January 2015 (UTC)


 * Great, that I can help by occuring errors ;-) I fixed it - no problems anymore. What size will you set for table_schema in the next version?


 * Oh, oops, I didn't actually specify what change to make! I'm glad you got it working anyway. The change I made was to change the type from VARCHAR(600) to BLOB, which should allow for an essentially unlimited size for the schema. Yaron Koren (talk) 21:30, 21 January 2015 (UTC)

Selecting calculated columns
I see that it's possible to select fields like COUNT(*). Is it possible to do more complex selections like the following?

I'm guessing not, since the commas in the if-statement would probably be interpreted as field separators. Any chance a custom separator could be defined similar to some SMW syntax? So a cargo query could be like:

--Jamesmontalvo3 (talk) 19:56, 27 January 2015 (UTC)


 * Actually, Cargo does a "smart split" on the "fields" parameter, ignoring commas contained within parentheses, so in theory just using commas should work there, though I haven't tried that particular query. Yaron Koren (talk) 01:04, 28 January 2015 (UTC)

Error on cargo_query coordinates field
My query:

in cargosqlquery i was getting undefined index errors.

function handleDateFields is getting called

and in line 802

$fieldDescription = $this->mFieldDescriptions[$alias];

The __long and __lat fields are failing

after looking at some other code i found the array_key_exists you use a couple times.

When i surround line 802-810 with this i get no errors.

if ( array_key_exists( $alias, $this->mFieldDescriptions ) )

Now when i switch format to googlemaps i get Fatal error: Cannot use object of type CargoFieldDescription as array in public_html/w/extensions/Cargo/formats/CargoMapsFormat.php on line 49

Isn't this functionality supported? should i be calling this some otherway?


 * Could you tell me the exact error message(s) you were getting, before you started making the code changes? Yaron Koren (talk) 18:54, 30 January 2015 (UTC)


 * ok i revert changes. the table display does work just giving these warnings.

my biggest problem is getting googlemaps output to work: see the fatal error at the bottom.

Notice: Undefined index: Location lat in /home2/juanitos/public_html/w/extensions/Cargo/CargoSQLQuery.php on line 802

Notice: Trying to get property of non-object in /home2/juanitos/public_html/w/extensions/Cargo/CargoSQLQuery.php on line 803

Notice: Undefined index: Location lon in /home2/juanitos/public_html/w/extensions/Cargo/CargoSQLQuery.php on line 802

Notice: Trying to get property of non-object in /home2/juanitos/public_html/w/extensions/Cargo/CargoSQLQuery.php on line 803

Notice: Undefined index: Location lat in /home2/juanitos/public_html/w/extensions/Cargo/CargoSQLQuery.php on line 802

Notice: Trying to get property of non-object in /home2/juanitos/public_html/w/extensions/Cargo/CargoSQLQuery.php on line 803

Notice: Undefined index: Location lon in /home2/juanitos/public_html/w/extensions/Cargo/CargoSQLQuery.php on line 802

Notice: Trying to get property of non-object in /home2/juanitos/public_html/w/extensions/Cargo/CargoSQLQuery.php on line 803

Fatal error: Cannot use object of type CargoFieldDescription as array in /home2/juanitos/public_html/w/extensions/Cargo/formats/CargoMapsFormat.php on line 49


 * Yikes! It looks like you uncovered two bugs at the same time. Sorry about that; I need to test my changes better. I just checked in fixes, so if you get the latest code from Git, hopefully everything will work fine. Yaron Koren (talk) 20:38, 30 January 2015 (UTC)

works, thank you so much. this extension rox, much better querying than semantic. http://i.imgur.com/mm0aJ0Y.png BUT WAIT! you made a new bug <,< http://i.imgur.com/xFn9Kak.png


 * I also could reproduce this bug and have even problems with display maps. Here my Code:
 * I only get the output
 * So the value is set, but not interpreted by Cargo - Martin  23:38, 31 January 2015 (UTC)
 * So the value is set, but not interpreted by Cargo - Martin  23:38, 31 January 2015 (UTC)
 * So the value is set, but not interpreted by Cargo - Martin  23:38, 31 January 2015 (UTC)


 * yeah i just switched my map display to a query for now as it does the same thing anyway.
 * Juanito jan 31
 * Juanito jan 31


 * I tried to change my code, like you did. Now the wired error is back. See: Error-PNG Any Idea? Martin jan 31


 * Sorry again - the #cargo_display_map problem was indeed a bug created by my fix for the other bug. I just fixed it, so I believe everything will work now if you get the latest version of the code, but of course I could be wrong. Yaron Koren (talk) 04:25, 1 February 2015 (UTC)


 * Yes it works for me now. Hey i don't know if this is related, but when i click semantic forms edit button on a page(table member) with coordinates field it doesn't remember or doesn't load the coordinates in the edit screen, so you have to specify the coordinates over again every edit. http://i.imgur.com/bwvKQp8.png


 * Ah, yes. That's not a bug in Cargo, it's a bug in Semantic Forms; though it's somewhat related to Cargo. I just fixed that bug, so if you get the latest SF code that problem should go away too. Thanks for letting me know about all of these. By the way, it's easier if you just link to the relevant page, instead of having a screenshot of it, given that it's a public wiki. Yaron Koren (talk) 16:01, 2 February 2015 (UTC)


 * one last bug i find with coords i think. I have a query form using NEAR command and gives me fatal exception. It loads the coords into the near command it ends up looking like this:where=(Location is null or Location NEAR (36.07491, -95.97656,500 km) http://juanitospeppers.com/w/index.php?title=Template:GlogQuery http://juanitospeppers.com/wiki/Special:RunQuery/GlogQuery

You've found a lot of stuff! Thankfully this one isn't as serious as the previous bugs. There are actually three issues here - one is a formatting problem, one is a Cargo bug, and one is somewhere in between. You're missing a closing parenthesis in the query's "where" parameter, and the "500km" should be "500 km" (that's the one that's halfway a bug). The definite bug is that "Location is null" should be "Location__full is null". Yaron Koren (talk) 18:02, 2 February 2015 (UTC)


 * lol yeah, not sure if thats good or annoying. Ok so 500km vs 500 km was causing the fatal error, added paren at the end for the where, So now the only thing that errors is Location is null (CargoSQLQuery::run Error: 1054 Unknown column 'Location' in 'where clause' ) -Juanito


 * See my last sentence before - you need to add "__full" to the query. Yaron Koren (talk) 20:22, 2 February 2015 (UTC)


 * oh ok sorry didn't know if that would get parsed automatically and fixed for me in extension =D. Also i had to remove my Varities is null as thats a join. ok so now... the near command is also returning records with a blank location(is not required field), can i make it not do that?


 * Are you sure it's not the "is null" check that's returning records with a blank location? Yaron Koren (talk) 21:19, 2 February 2015 (UTC)


 * you're correct, sql is not behaving as i expected, sorry..  keep up the good work! - Juanito

Different displays for coordinates
Do you think it'd be possible to have a display for coordinates that got the state/province and country the point is in?


 * Well, the issue there is not the display, but the lookup, known as "reverse geocoding". It would be cool to have that and other "GIS" capabilities in Cargo, although I have no specific plans to add them at this point. Yaron Koren (talk) 17:24, 3 February 2015 (UTC)

Cargo queries not refreshing
I was having problems with queries not updating when an item was added to table. had to manually click refresh, which isn't really feasible if multiple users editing lots of page simultaneously so i $wgParserCacheType = CACHE_NONE; $wgCachePages = false;. Is that the best way to accomplish that?


 * For smaller wikis, that solution works fine. If you're worried about performance, though, you can use the MagicNoCache extension and just add " __NOCACHE__ " to the pages that contain queries. Yaron Koren (talk) 15:31, 6 February 2015 (UTC)

Left join
Hi Yaron, we could use a 'left join' very well. Are special joins available somehow? - AdSvS (talk) 10:15, 12 February 2015 (UTC)


 * Actually, every join Cargo does is a "LEFT OUTER JOIN". Or would you prefer that it be without the "OUTER"? If so, can you explain the use case? It might be tricky to implement. Yaron Koren (talk) 15:55, 12 February 2015 (UTC)


 * I have 2 tables and want all the rows of the first table that are not in the second. So that would produce something like: . But this produces an error (Fatal exception of type MWException).--AdSvS (talk) 17:07, 12 February 2015 (UTC)


 * That's interesting. What about using "NOT IN" instead (assuming that would work)? Yaron Koren (talk) 17:53, 12 February 2015 (UTC)


 * Close Yaron! 'NOT EXISTS (SELECT * FROM cargo__Table2 WHERE cargo__Table1.key = cargo__Table2.key)' does the trick! So the table names have to include the prefix but the rest is quite straightforward (and I don't consider myself an SQL junkie ;-) ).--AdSvS (talk) 09:07, 13 February 2015 (UTC)

Query form example
on your example http://discoursedb.org/w/index.php?title=Template:Item_query you have 2 fields, this goes into a cargo query. I have implemented the same thing on my site but for the life of me can't get it to behave like yours. I fear it may be some different version of database or something, but figured i would ask you.

On your site i put an author: "tt" it returns all items with author contains tt, it seems like it ignores the other field because it's null right?

But in mine if i search author: "tt" and leave the other one blank, it returns no results because the 2nd field


 * Did you finish this question? Anyway, if you're using the exact same template and form, then I would have to imagine that, yes, the difference is in the database. Yaron Koren (talk) 14:19, 13 February 2015 (UTC)