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)


 * Ah - after seeing that I got scared about potential abuse of internal SELECT calls, and I just checked in code that rejects any such calls - sorry. :( (And sorry about giving you that advice in the first place.) But now that I look at your original #cargo_query call again, it seems like it should work. Maybe the issue is just the "join on" parameter, which should have a "=" instead of a ","? Yaron Koren (talk) 02:29, 16 February 2015 (UTC)

Allowed values list definition ( SMW "Allows value" property)
Hello, i'm very exciting by your new borned initiative but have to start very soon a new project for my company (kind of project / users-skills database). I already made a mockup with SMW/SF of this application. Now starting in developping the application... I m'trying to check if we can start with Cargo or if we have to start with SMW and plan a futur migration ...

So first question (maybe some other will follow ... )

One thing I use in SMW, that I didn't find in Cargo, is the capability of defining complexe structured list of allowed values by using the property pages with the allows value special property and the tranclusion capabilitie. Then one definition of list can be used to fill differents fields of differents templates (example : a list of technologies can be used to fill the technical skill field of a user and a technical needs for a project !)

In Cargo, the definition of list of allowed values for a field is directly defined inside the template it-self. Then, for my example, I'll need to define twice my technical items list (in the projet's template and in the user's template). Is there anyway to define my list in specific pages (not inside the template ?) to be included in my both templates.

thanks

Guillaume.


 * I'm glad you're trying out Cargo! I never thought about doing that kind of transclusion in SMW. In theory, that same sort of transclusion should work in Cargo, though I've never tried it... if that doesn't work, you'd have to do the duplicate listings. Yaron Koren (talk) 18:32, 17 February 2015 (UTC)

Does that work with sqlite ?
Learning MediaWiki and trying to play with Cargo ; extension installed, update.php done, 2 new tables ; testing a template (copy pasted from Quick start guide) : This is the "Book" template.

Gives me an error after saved :.

Short text printed out says at the end that  No new tab I can see.

Is sqlite the culprit, or me ? Thank you. --Abclf (talk) 15:46, 17 February 2015 (UTC)


 * There might not be an issue there at all - the "uncommitted DB writes" thing might just be a temporary hiccup. You don't see a "Create data" tab or dropdown action on that template page? Are you using a custom skin? Is your user account an admin? Yaron Koren (talk) 18:35, 17 February 2015 (UTC)


 * I'm using a native mediawiki almost pristine install, sqlite storage, Windows and xampp localhost. I'm the only one user. Re-testing the process I was finaly able to find out, near the search form, a new a dropwdow menu showing the "create tables" step I was looking for. I guess I was not logged in as admin and, no matter what, the action is a bit hidden for naive newcomer. Thank you for your help. --gilles (talk) 21:33, 17 February 2015 (UTC)


 * Okay, great. The placement of the dropdown actions is a choice of the skin designers, and not something I have control over; but maybe the documentation would be improved with a screenshot of that dropdown or something. Yaron Koren (talk) 21:59, 17 February 2015 (UTC)


 * Please can you confirm this extension is tested with sqlite storage ? Using your Template Book example : once page saved, clicking on the new create data link is hitting a memory related issue linked to sqlite :  and nothing new in any of the two Cargo tables (still empty). --gilles (talk) 12:41, 18 February 2015 (UTC)


 * No, this extension has unfortunately not been tested yet with any database system other than MySQL. I wouldn't be surprised if there's a problem with the SQLite handling, and your feedback is helpful. Yaron Koren (talk) 16:22, 18 February 2015 (UTC)

Cargo with holds template
I have a form that holds a template for a field. In the page source i get: |Images=

In the cargo table i get the template after it has been called, is there a way to get the above text instead? {|class="wikitable" ! Image ! Comment
 * ENCODED_EIMAGE_CONTENT PGltZyBzcmM9Imh0dHA6Ly9pLmltZ3VyLmNvbS9kUlF4M281LmpwZyIgd2lkdGg9IjgwMCIgdGl0bGU9IiIgLz4= END_ENCODED_EIMAGE_CONTENT
 * Comment::plant with different stages of fruit
 * - }


 * I'm not sure I understand - you want users looking at that page to literally see that wikitext? Yaron Koren (talk) 18:38, 17 February 2015 (UTC)


 * i want to format the data before the user sees it. In the above instance i wanted to change the template name from PicturesBig to PicturesSmall (because i want to display all the images in the field as a smaller gallery type thing.


 * Okay, now I'm confused about the "PicturesSmall" thing - if you want to change it, why not change it? And what does that have to do with Cargo? Yaron Koren (talk) 22:01, 17 February 2015 (UTC)


 * well i'm doing a cargo query to get the field. here look at http://juanitospeppers.com/wiki/7_Pot_Brain_Strain,_Red_review_001

here we see this pages source:

here is how it's stored in cargo: http://i.imgur.com/L4wR5t2.png

So what am i saying is when i do a cargoquery why can't i get the raw value for images field instead i get the rendered template. Is there something in the cargo store call i can do to get it?


 * Okay, now I get it. Probably not, though. The issue isn't with Cargo, but with MediaWiki parsing: by the time the main template ("Review") is called, the arguments to it have already been parsed - the "Review" template has no way to know what the original wikitext was. Maybe there are other solutions, like just passing in the image URL? Yaron Koren (talk) 04:51, 18 February 2015 (UTC)

Ok thanks for the info wasn't sure how / when the cargo store happened. i'm thinking i'll have to redesign the way i handle images and not use holds template field.

Cargo data structure update
Hi Yaron, when you modify a template (adding a field for instance), you need to recreeate your storage table associated to this template then you loose all your datum. Is ther any way to automaticly refill your table with existing datum ? Thanks
 * the recreate refills the table for me... -juanito
 * Strange, when I modify my template, (adding an attribut) when click "recreate data" the tables are rebuilt but when i check the table content by clicking on Special:CargoTables/Books the table is empty. :-( - which version do you use ? -guillaume


 * The refilling is all done via MediaWiki jobs. Maybe the jobs aren't getting run, or you still have a backlog of non-Cargo stuff in your job queue? Try running runJobs.php. Yaron Koren (talk) 16:23, 18 February 2015 (UTC)


 * Thanks, you're right, I had problems with my jobs, it's now ok Guillaume Prêcheur (talk) 11:42, 1 March 2015 (UTC)

SemanticForms Dropdown list not filled ?
hello Yoren,

In this following example, my dropdown lists associated to the fields 'Type' and 'Qualite' should contain "Visuel or Document" and "Bonne,Mauvaise" values. But Nothing, the dropdown lists are empty ... In the main MagProjet Form (editing the projets informations of my project object), the fields I declared at the beginning of my work are still working, but when I tried to had one new on it, it doesn't work.


 * 1) did I miss, something -where am I wrong ?
 * 2) how can I debug my staffe ?
 * 3) what the minimum things to do from the modification of a template and form definition to make appear the effect in the formular (do I need to activate specials jobs ?)

Thank you very mutch for answering.

Here is my MagDocumentProjet template :



And here is my form using the template : Ceci est le formulaire « MagProjet ». Pour créer une page avec ce formulaire, entrez le nom de la page ci-dessous ; si une page avec ce nom existe déjà, vous serez dirigé vers un formulaire pour l’éditer. Modèle associé : Template:MagProjet




 * (définition of main form)
 * (définition of main form)

Guillaume Prêcheur (talk) 10:07, 5 March 2015 (UTC)