Extension talk:Cargo

From MediaWiki.org
Jump to: navigation, search

Looking for a way around duplicate rows[edit]

I have the infamous duplicate rows bug. Fortunately, this isn't actually much of a problem most of the time, since I can just add "|group by=_pageID" to most Cargo DB queries and then it will just return distinct rows from the database, even if they are actually doubled in the database. However, I have not yet found a way around the duplicate row problem when I query an aggregate function like SUM or COUNT. In particular, I am trying to do something like this:

{{#cargo_query: tables=Games |fields=SUM(Bronze) |where=GamePlatform="PS3" }}

Unfortunately, I can't just tack "|group by=_pageID" onto the cargo_query, since that causes the aggregate function SUM to work on a per-group basis (i.e., instead of returning a single row containing the total sum of the Bronze column, it returns many rows, and each row tells me the sum of Bronzes with that particular _pageID is in the database). This wouldn't be a problem if subqueries were possible or something like that, but I haven't been able to find a Cargo-friendly way of grouping by _pageID and then counting/summing the resulting rows. Any thoughts? Thanks in advance! NathanielJ (talk) 17:22, 12 October 2017 (UTC)

I was running into this problem the other day. No solution, but one thing I'm thinking about is putting a unique index on all user-facing columns, to prevent the dupes from ever being saved. I'm not sure if that'd just make Cargo fail to insert in a ugly way though. It mightn't be too hard to add IGNORE to the insert queries; seems like something Cargo might already do anyway, I'm not familiar with the code. Sam Wilson 22:44, 12 October 2017 (UTC)
I was actually going to write a totally different reply - explaining that these are not good options, the best solution is to just use the command-line option for now, etc., when Sam Wilson's suggested solution made me realize that there's a very reasonable solution for this problem that I had been neglecting until now. The code can simply check, before adding a new row to a table, whether a row already exists with that exact same set of data, and then stop adding that row if there is one. I had thought about that solution various times before, but had always rejected it because there can in fact be valid duplicates - a page can have multiple, identical calls to a template, for various reasons. However, I've never heard of this actually happening, and conversely, unwanted data duplication has been a major problem. So I just added this check to the code - in the current Cargo code, a row that looks like a duplicate will simply not get saved. Hopefully there's a nicer long-term fix, but for now, the issue of data duplication may be over! If duplication is a problem for anyone, please try out the latest code. If it seems to work, I'll probably release a new Cargo version soon. Yaron Koren (talk) 16:00, 13 October 2017 (UTC)
If anyone's reading this - there was actually a bug in that fix, which I think I just fixed, so if you try to use this new feature, please make sure to get the very latest version. Yaron Koren (talk) 21:41, 20 October 2017 (UTC)
Thanks for these changes, Yaron Koren. For those able to run the very latest code, have these fixes (there are several) resolved the issue of row duplication? —Pangaearocks (talk) 17:10, 24 October 2017 (UTC)
I believe so, though I'm not making any guarantees yet. But it works for me. Yaron Koren (talk) 17:42, 24 October 2017 (UTC)

Links/images sometimes displaying as plaintext[edit]

I've read through the archives and didn't see a similar issue, so hopefully haven't missed something obvious. I'm using the following query to generate rows:

{{#cargo_query:
tables=Link_Skill
|fields=linkname,troupe,chara1,chara2,chara3,chara4,description,attribute,bonus
|where="{{PAGENAME}}" IN(chara1,chara2,chara3,chara4) OR troupe="Spring"
|format=template
|template=Link Skill/Row
|named args=yes
|order by=bonus="Co" DESC,bonus="Ac" DESC,bonus="Sr" DESC
|limit=10
}}

The template being used to format it includes icon images. Half the time this will display on the page as intended, but on occasion it just breaks and just shows the HTML instead:

<img alt="Action" src="/a3/images/thumb/c/c2/Action.png/20px-Action.png" title="Action" width="20" height="21" srcset="/a3/images/thumb/c/c2/Action.png/30px-Action.png 1.5x, /a3/images/thumb/c/c2/Action.png/40px-Action.png 2x" /> Ac 10% Up

It usually rights itself if I modify the query in some way and resave the page. I'm not really sure what's causing it. Any help would be appreciated. --Rurikawa (talk) 13:40, 13 October 2017 (UTC)

Is it the same images that fail, or is it a different set every time? And if it's the same images, does there seem to be any pattern to which images fail? Yaron Koren (talk) 16:01, 13 October 2017 (UTC)
It's all of the images at once. There doesn't seem to be a pattern. It happens with another similar query elsewhere as well. Rurikawa (talk) 06:38, 14 October 2017 (UTC)
For what it's worth, this happens on my wiki as well, and it's not limited to images --- it happens with any HTML thatis created by format=template. I believe that it may be some kind of conflict with Extension:ConfirmEdit (do you have it installed?), and purging the page's cache seems to fix the issue. NathanielJ (talk) 02:36, 20 October 2017 (UTC)
Ah yes, we do have ConfirmEdit installed. Cheers for that! Rurikawa (talk) 20:45, 25 October 2017 (UTC)

Cargo query error[edit]

After making new templates and changing truckloads of pages, I'm finally ready to start connecting some of the data with Cargo. However, I ran into a snag, and wonder if this is due to running Cargo 1.3.1, a silly error on my part (I'm learning as I go), or something else. Could somebody please elaborate?

This is the test query I'm trying out. Quest_poe1.location is a List (;) of Page

{{#cargo_query:
tables=Quest_poe1,Location
|join on=Quest_poe1.location=Location._pageName
|fields=_pageName=Quest,location
|where=location HOLDS "Caed Nua"
}}

This yields a rather long error message: https://i.imgur.com/ABlUVBV.png

(These are the Cargo tables) —Pangaearocks (talk) 16:54, 15 October 2017 (UTC)

You just need to put a table name before "_pageName" in "fields=" - both tables have a "_pageName" field, so the query doesn't know which one to use. Yaron Koren (talk) 03:28, 16 October 2017 (UTC)
Thanks. That got me another error, so I must be doing something wrong somewhere. Have attempted so many different things, but this looks right to me? Yet I'm told Error: 1054 Unknown column 'cargo__Quest_poe1.location' in 'on clause' (127.0.0.1:5002). Quest_poe1.location is a list field.
{{#cargo_query:
tables=Quest_poe1,Location
|join on=Quest_poe1.location=Location._pageName
|fields=Quest_poe1._pageName=Quest,Quest_poe1.location=QuestLocation,Location._pageName=Location
|where=Quest_poe1.location HOLDS 'Caed Nua'
}}
In a different attempt I tried join on with HOLDS, which yielded another error message. The info here is correct I assume? HOLDS examplePangaearocks (talk) 05:35, 16 October 2017 (UTC)
Yes - given that "location" is a list, it needs to be "join on=Quest_poe1.location HOLDS Location._pageName". Yaron Koren (talk) 13:24, 16 October 2017 (UTC)
Thank you - that helped and got rid of the errors :) We have run into another one, though, which is a strange one. When running a query, we get many more rows than should be there. There are hits on pages that don't contain the data we are searching for in the query. I've been in touch with another admin who knows and works with SQL, and we've run different sorts of queries on different tables. He suggests it might be a caching issue. Are there any settings that might cause this, and which we can change so that queries yield the right results immediately? We've resorted to force refreshing pages, which has got rid of some of the many duplicates an erroneous hits.
Running the above code (with your fix), here is an example of the hits we get, on this test page. Many of these have nothing to do with "Caed Nua", and others don't have any location set yet. Another example was getting all 5 rows when searching for 'Iron' on Nation.products, which also is a list field, using HOLDS. —Pangaearocks (talk) 19:43, 16 October 2017 (UTC)
What's an example of a page that shouldn't be in the results? Yaron Koren (talk) 01:58, 17 October 2017 (UTC)
Quite a few actually. For instance His Better Half, Into the White Void, Safe Haven, Songs of the Wild, The Termal Pearl. —Pangaearocks (talk) 15:49, 17 October 2017 (UTC)
This looks like a bug with the handling of HOLDS in the "join on" clause. There was a fix for "HOLDS" handling that was done in August, here - I think this was after the version you have. I would recommend upgrading to Cargo 1.4 - and ideally to the very latest code, which contains a possible fix for the duplicates problem - to see if that solves your problem. Yaron Koren (talk) 01:46, 18 October 2017 (UTC)
Thanks for confirming this was due to a bug (we're on the 1.3.1 version). As the wiki is located on a wiki farm (Gamepedia), I can't update extensions myself, but the good news is they'll update to Cargo 1.4.0 in the near future, so that should get rid of the HOLDS query issue. That is great news, because it means I can start connecting data on pages from multiple tables. The most recent commit won't be included, but another version of Cargo is released, I hope they can roll out that update too in the near future. Sounds like a good workaround for the duplicate rows issue, which could help a great deal of people :) At least right now, we have a bigger problem with tables not filling out properly, so if you manage to find a fix for that too, it would be great. —Pangaearocks (talk) 20:02, 19 October 2017 (UTC)
The good news is that Cargo has been updated to 1.4. The bad news is that the query with the double HOLDS is still throwing doubles and triples of data, and false positives. There aren't doubles or triples in the actual database, so shouldn't both these issues have been solved since upgrading to 1.4? Do you know what else might be wrong? I've tried many Purges/Refresh and editing the query page, but it hasn't solved it. Query page. —Pangaearocks (talk) 19:01, 26 October 2017 (UTC)

I still think this is a bug with the handling of "HOLDS", although clearly it hasn't been fixed yet. Right now that page isn't showing anything relevant - could you please get this problem to appear again? Yaron Koren (talk) 03:52, 30 October 2017 (UTC)

Sorry about that, I changed the tablename. But I intended to come back to you, so I'm glad you already stated there is probably an issue with HOLDS. Have made some other queries with a single HOLDS, and I still get false positives, and duplicate entries. Some of those don't have a location set, yet get hits in queries. Others have locations set, but not what I'm querying for, yet shows up in the results. Check out the same page again, where I made some other queries. One of them is:
{{#cargo_query:tables=Quest_poe1
| fields=_pageName,locations
| where=Quest_poe1.locations HOLDS "Copperlane Catacombs"
|format=ul
}}
If you manage to find out what's wrong and fix it, please put out another version of Cargo in the not-too-distant future :) I'm also really intrigued about the table rebuild commit the other day. —Pangaearocks (talk) 18:35, 30 October 2017 (UTC)
Long URLs so I hope it works: by using a different query, you can see some of the places where it goes pear-shaped. On "The Trials of Durance" quest, only two locations are set: Picture proof. But using the query in the link above (with the View Data option), it gets a whole string of hits, including what the query in the previous post queried for (Copperlane Catacombs). Hope this may help in locating the underlying issue. —Pangaearocks (talk) 17:08, 31 October 2017 (UTC)

How to fill the table for calendar display?[edit]

Hi, I have just started with Mediawiki and one of the basic functionality I'd like to have is calendar displayed on my main page. So I installed Cargo with external mysql database, I created simple template:

<noinclude>
To jest szablon „Urlopy”.
Powinien zostać wywołany w następującym formacie:
<pre>
{{Urlopy
|Pracownik=
|Termin=
}}
<//pre> // Here it was with one / but I wasn't able to paste it here correctly with it.
Edytuj stronę, aby zobaczyć tekst szablonu.
{{#cargo_declare:_table=Urlopy|Pracownik=Text|Termin=Date}}
</noinclude>

<includeonly>{{#cargo_store:_table=Urlopy|Pracownik={{{Pracownik|}}}|Termin={{{Termin|}}} }}{| class="wikitable"
! Pracownik
| {{{Pracownik|}}}
|-
! Termin
| {{{Termin|}}}
|}
</includeonly>

I see the table is created, but I can't figure out how to add data into it. Could you please help? Daniel

Now you just need to create pages that call the "Urlopy" template - you can do it hand, or set up forms to do it using Page Forms, or do a mass creation from a file using Data Transfer. Yaron Koren (talk) 13:11, 18 October 2017 (UTC)
Working perfectly. Thank you! Daniel

fullcalendar.io locale change[edit]

Hi, is it possible to change fullcalendar.io locale? I know it can be done (according to the fullcalendar documentation: <script src='fullcalendar/locale/es.js'></script>), but I have no idea how to apply it in Cargo.

I'm amazed to see that all of the "calendar" format display is hardcoded in English! I thought at least some of it was getting translated, but I guess not. I'll have to look into this. Yaron Koren (talk) 17:34, 20 October 2017 (UTC)

Performance testing[edit]

Regarding this test, which was apparently run over two years ago: Performance testing Has other more recent tests been carried out, comparing SMW and Cargo, maybe on a larger scale as well? It would be interesting to know more about the speed and resource differences between the two setups. —Pangaearocks (talk) 19:53, 19 October 2017 (UTC)

Yes - that test was run a while ago, and now it can't even be re-run, because that wiki no longer has SMW installed on it. I'm not aware of any other performance tests. Yaron Koren (talk) 17:35, 20 October 2017 (UTC)

When do tables need to be re-created?[edit]

Figured it was best to put this in a separate 'thread'. As I'm busy converting templates from using SMW (or often nothing) to Cargo, fields may need changes along the way, as I discover the template isn't quite ideal. For instance changing a field from Page to List (;) of Page. Or more simple changes like auto-categorisation, or formatting different things in the infobox.

How serious must the changes be to require a re-creation of the Cargo table itself? Is Cargo able to spot slight changes to the template and update the fields and data accordingly, or should we recreate the table if there have been any changes to the cargo_declare or cargo_store sections? —Pangaearocks (talk) 20:10, 19 October 2017 (UTC)

I think only changes to #cargo_declare require recreating the data - if only #cargo_store is changed, I think just the template re-save will trigger all the pages' data to get refreshed. I could be wrong about that, though. But yes, any change to #cargo_declare that would cause the DB table schema to be modified requires a recreate. Yaron Koren (talk) 17:38, 20 October 2017 (UTC)

No blank alias anymore?[edit]

It used to be possible to have field_name= to keep the field name or an alias from displaying in the final format. Not sure when it stopped working and I am still on 1.3.1. But removing the equal sign or adding text for an alias fixes the issue. Error: no field named "" found for any of the specified database tables. --192.231.41.175 21:57, 21 October 2017 (UTC)

Special characters in page names[edit]

I'm having some issues with a few pages that have special characters in them. What is the best way to deal with this, given that we want pages to reflect the real names of characters in the game? Some examples are:

  • Will-O'-Wisp (database error, but can use " instead of ' when querying here. Used ' since documentation stated it was preferred over ")
  • All Hands on Deck, with people called Waldr "Three Fingers" and "Lefty" Lisc. I've used semicolon (;) to separate List of... which means that here the names get incorrectly separated given that " is used. See the page values.

Sorry for the overload of questions and images, but since I want to use Cargo and drop SMW, I'd like to clear out all big and minor issues :) —Pangaearocks (talk) 17:07, 24 October 2017 (UTC)

The first issue probably requires a change to the wikitext, unfortunately - you can have something like "{{#replace:{{PAGENAME}}|'|\'}}" instead of "{{PAGENAME}}" in the template. The second one seems like a bug in Cargo, though thankfully just with display, not with storage - that's why the data shows up correctly some of the time. Yaron Koren (talk) 17:53, 24 October 2017 (UTC)

Join Conditions[edit]

Took a look at the code, specifically in CargoSQLQuery.php, and started wondering about join conditions. The code uses "LEFT OUTER JOIN" and "RIGHT OUTER JOIN". But not "INNER JOIN". W3schools.com has a nice comparison image, so won't this cause some issues?

Thinking about this query for instance, and remembering that some of the problems I had before was with pages where no locations (list field) were set:

{{#cargo_query:tables=Quest_poe1
| fields=_pageName,locations
| where=Quest_poe1.locations HOLDS "Copperlane Catacombs"
|format=ul
}}

When there is no locations set in the page, the intention (in my mind at least) is that the query shouldn't get results, but with LEFT OUTER JOIN it will, because the first table will always yield hits. Maybe this isn't an issue most of the time, I don't know, but when the field you query for is empty, it looks like there will be false positives. Maybe this is what is happening in the HOLDS query I got help with before?

Naturally I don't understand all the code in that Cargo SQL page, and maybe there are perfectly valid reasons for using outer joins. There are certainly uses for it. But my understanding has been that INNER JOIN is the "default" use, because you typically want to see results that are unique to both (or more) tables. —Pangaearocks (talk) 02:38, 6 November 2017 (UTC)

Display event end time in fullcalendar[edit]

Hello, is there any way to display not only a start time, but an event end time also, in case that the event is not full day? Regards, Daniel

Yes - you can use the "start" and "end" field aliases; see here. Let me know if it doesn't make sense, or it doesn't work. Yaron Koren (talk) 14:27, 7 November 2017 (UTC)
Hi Yaron, "start" and "end" field aliases are working for me when I use them to extend an event for a few days with 'Date' type fields. But not working, when I use to two 'Datetime' type fields. Still I have displayed only start hour. Any ideas?
That's an interesting quirk I didn't know about, of the JS calendar library that Cargo uses, FullCalendar - by default, it only shows the start time, not the end time, of events with times. I don't know why it does that, but I agree that it's better to show both, so I just checked in a change to the code so that now it also shows end times. Yaron Koren (talk) 16:55, 9 November 2017 (UTC)
Cool! Thank you for such a quick support. BTW. I see in the same commit 'agendaWeek' option. Is it possible to set it as default view? 'week' makes 'basicWeek'
Ah, good point, I forgot about that. I just checked in a fix for this. Yaron Koren (talk) 23:06, 10 November 2017 (UTC)

Can't get template to create tables[edit]

In the past I successfully had Cargo installed on a testmachine and was able to use templates to fill tables. Now developers have installed cargo for me on our main site and I'm running into trouble: I create a template with #cargo_declare and #cargo_store but after saving, the template page does not show the "Create Table" link.

  • I checked in the mysql database that the cargo_pages and cargo_tables tables were created after running mediawikis update.php
  • I manually ran php cargoRecreateData.php, no error was returned but also no other message displayed
  • I ran action=cargorecreatetables&template=Glossary and it returned a simple:
{
    "success": ""
}
  • in between I also tried saving out the template again with slight modifications.
  • on the Special Pages I can see the cargo relevant pages but Cargo Tables page only shows "The following tables are defined:"

Are there any other ideas of what I could check? MidiaWiki 1.28 / Cargo 1.4

I'm guessing that there's a problem with the #cargo_declare call. Could you pastebin the template contents? Yaron Koren (talk) 01:05, 8 November 2017 (UTC)
Thanks Yaron, here it is: https://pastebin.com/dh57iEL7
That's very odd - the template definition looks totally correct, and I actually tried it out myself (including running that API action), and the table was created correctly. Is that exactly the template you used? Or did you simplify it, or change the language or something, from what's on your wiki? Yaron Koren (talk) 04:08, 8 November 2017 (UTC)
No that's exactly the template as I have it. (http://wiki.derivative.ca/index.php?title=Template:Glossary) I'll have to inquire with the website people what else they did when installing mediawiki. Also removed Cargo and installed it again via an git submodule - same thing. Perhaps I should start disabling more and more extensions - could there be a conflict? Although I suppose I would see an error somewhere.
Oh, it's a public wiki. This is very odd indeed... do you have access to the database for this wiki? If so, it would be very helpful to run the following query on it: " SELECT * FROM page_props WHERE pp_propname = 'CargoTableName' ". It looks like something is getting messed up in saving to that table. Yaron Koren (talk) 12:11, 8 November 2017 (UTC)
Hi Yaron, it returns an empty set. The propname column just contains displaytitle, notoc and forcetoc entries when i do a select * --66.207.201.146 16:37, 8 November 2017 (UTC)

Alright. Well, that explains why you're seeing this problem... although I have no idea why that's happening. The only thing I can think of is an option you suggested before, that some other extension there is conflicting with saving data to the page_props table. I would suggest temporarily disabling all extensions except for Cargo, then re-saving that template, and seeing if that makes a difference. If it does, then it's a matter of isolating the extension(s) causing the problem. Yaron Koren (talk) 22:05, 8 November 2017 (UTC)

Hi Yaron, I did get a bit further with this after our webdevs installed MediaWiki 1.29.1 I am now able to create tables and they are displayed in the database. My next problem was that the table would not be populated and eventually I found out that I should not use the term Long as a column in the cargo table. I think I'm getting a bit further with this - thanks for all the help--66.207.201.146 20:15, 8 December 2017 (UTC)

How to delete table[edit]

Hi Yaron,

I have a problem with one table that makes PHP 500 Error when I go to Special:CargoTables. So I decided to create it again, but how to remove the old version? I removed table template, it doesn't exists anymore in my DB, and I am able not to open Special:CargoTables. But next to my table name it says "This table is registered, but does not exist!". Registered where?

Cheers, Daniel

That means it's "registered" (has a row) within the cargo_tables DB table. I can't remember now if there's a way to get out of that state (row in cargo_tables but no actual table) from within the web interface - you may have to manually delete that row from the table, if you have SQL access. Yaron Koren (talk) 01:20, 13 November 2017 (UTC)
This rings a bell with me. I think I had a problem recreating a table which had been deleted. I think the solution was to remove it from limbo by deleting a row in the database before recreating the table. Jonathan3 (talk) 01:29, 14 November 2017 (UTC)

Calendar not displayed with version based on FullCalendar v3.6.2[edit]

Hi Yaron,

I was using Cargo version based on FullCalendar v2.3.2. After all your updates that I have asked for in the recent days I decided to switch to the latest version which is using FullCalendar v3.6.2. Unfortunately I can't display calendar now. Even simple query that I had earlier doesn't show it: {{#cargo_compound_query: tables=Urlopy; fields=_pageName, Pracownik=name, Start=start, Koniec=end; color=#E74C3C |format=calendar }} Only header buttons are presented (but even header title is missing).

My MediaWiki is 1.28.2 and jQuery 1.11.3

If you could please help also with it. Cheers, Daniel

I was worried that would happen... MediaWiki switched from jQuery 1 to jQuery 3 in version 1.30, and I was hoping that there could be one version of the FullCalendar library that would work with both versions, but that doesn't seem to be the case. I just checked in a change so that Page Forms now includes two different versions of FullCalendar (2.9.1 and 3.6.2), and uses one or the other depending on the MediaWiki version. If you can, please upgrade to the very latest code and let me know if that fixes the problem for you. Yaron Koren (talk) 22:27, 13 November 2017 (UTC)

List of authors with Christian and surname separate[edit]

I would like to have a list of authors for each item. Some authors will be organisations, some will be individuals. For the individuals I'd like to be able to output the names as "Joe Bloggs" or "Bloggs, J" or "Bloggs, Joe" or any other combination. What would be the best way to do this?

I was thinking of saving the names (for individuals) with a delimiter like a colon between the two parts, e.g. "Bloggs:Joe". Are there parser functions that, where the ":" is present, would be able to extract/separate the parts for display purposes? I guess for lists of multiple authors I could then use arraymap to do this for each author. Or would I need to use Scribunto/Lua, or something else, instead? Thanks. Jonathan3 (talk) 23:23, 11 November 2017 (UTC)

P.S. I suppose firstname1, surname1, firstname2, surname2, firstname3, surname3, etc for perhaps 10 pairs might do the job, but it's not as neat and doesn't use Cargo's List functionality. Jonathan3 (talk) 23:26, 11 November 2017 (UTC)

Some combination of #arraymap and #explode might do the trick. Conversely, you could have a separate template just to hold a full author name, and then make that a multiple-instance template within the form - if that makes sense. Yaron Koren (talk) 01:18, 13 November 2017 (UTC)
I will have to read the documentation to understand the multiple-instance template idea. What difference would it make to the way the main table is treated by the drillldown page, and queries etc? Jonathan3 (talk) 09:05, 13 November 2017 (UTC)
If you use a separate template for names, then they would go into a separate table - querying would still be possible, using a "join", but drilling down on all the data together would not. (One of the to-dos for Cargo is to allow drilling down on multiple related tables.) If drilling down on names is important, you may be better off keeping everything in one template and table, although there would be some level of hackery involved. Yaron Koren (talk) 15:52, 13 November 2017 (UTC)
Yes, I'd like to be able to drilldown on names, so that to-do sounds good. In the meantime I'll likely use the format "Bloggs, Joe" with the comma as a delimiter so that it looks OK in drilldown etc, but use {{#explode:}} when I want to show it in another format. Jonathan3 (talk) 22:07, 13 November 2017 (UTC)
"Some combination of #arraymap and #explode might do the trick." I can confirm that this does work, in conjunction with the template output type (to allow the parser functions to be used). I used List (;) of String and the semi-colons look fine in between "Bloggs, Joe"-format names. Jonathan3 (talk) 01:33, 14 November 2017 (UTC)

size parameter for Wikitext fields?[edit]

Do Wikitext type fields also have a default length of 300, as String and Text do? The docs currently say: size= - for fields of type "String" and "Text", sets the size of this field, i.e. the number of characters; for "Text", the default is 300Sam Wilson 02:20, 23 November 2017 (UTC)

Yes, the default for "Wikitext" is also 300. The documentation for "size" was way off! I guess I just didn't update it in a long time. I updated it now. Yaron Koren (talk) 04:32, 23 November 2017 (UTC)
Thanks! Sam Wilson 05:00, 23 November 2017 (UTC)

Add Row With Some Static Data and Some Data from Another Row[edit]

I'm trying to add a new row to a cargo table which has some new data and also uses data from an existing row for "everything else". For example, if I have:

Name Age Size Weight
Bob 23 Medium 175
Alice 42 Small 100
Ted 15 Large 155
George 96 Titanic 2505

And I want to add a new row, called "Tom", with a new age, "61", but use Bob's other data (size, weight), my template has the following information:

Name = Tom
Age = 61
Use-Existing-Row = Bob

How do I go about this? I'm trying to use a query for Bob's data in the Size and Weight fields (in the "#cargo_store:" section):

| Size = {{#cargo_query:
table=Silly
|fields=Size
|where=_pageName='Bob'
}}

But I don't end up creating a new row, much less inserting new and old data into it. How do I do this? (Please let me know if this example doesn't give enough info). Thanks! --Nuada99 (talk) 03:47, 1 December 2017 (UTC)

Is this wikitext snippet from a page or a template? If it's from a page, it shouldn't be calling #cargo_store directly; and if it's from a template, the value (like 'Bob') shouldn't be hardcoded. Yaron Koren (talk) 00:07, 1 December 2017 (UTC)

Templates, which are feeding into templates, actually. :) So, there's one table, but two templates which feed into it:

Template:Silly
<noinclude>
{{#cargo_declare:
_table=Silly
| Name = String
| Age = Integer
| Size = String
| Weight = Integer
}}
</noinclude><includeonly>
{{#cargo_store:
_table=Silly
| Name = {{{Name|}}}
| Age = {{{Age|}}}
| Size = {{{Size|}}}
| Weight = {{{Weight|}}}
}}
* {{{Name|}}}
* {{{Age|}}}
* {{{Size|}}}
* {{{Weight|}}}
</includeonly>

So far, very basic. Then there's several basic pages, which make use of this template, to provide data:

{{Template:Silly
| Name = Bob
| Age = 23
| Size = Medium
| Weight = 175
}}
{{Template:Silly
| Name = Alice
| Age = 42
| Size = Small
| Weight = 100
}}
{{Template:Silly
| Name = Ted
| Age = 15
| Size = Large
| Weight = 155
}}
{{Template:Silly
| Name = George
| Age = 96
| Size = Titanic
| Weight = 2505
}}

Here's where it gets more complicated. There's a second template, Silly-Mod, which should build additional rows into the same "Silly" table, but re-use data, based on other rows, as specified:

<noinclude>
{{#cargo_attach:
_table=Silly
}}
</noinclude><includeonly>
{{#cargo_store:
_table=Silly
| Name = {{{Name|}}}
| Age = {{{Age|}}}
| Size = {{#cargo_query: table=Silly |fields=Size |where=_pageName={{{Existing-Row}}} }}
| Weight = {{#cargo_query: table=Silly |fields=Weight |where=_pageName={{{Existing-Row}}} }}
}}
* {{{Name|}}}
* {{{Age|}}}
* {{{Size|}}}
* {{{Weight|}}}
</includeonly>

I then create a new page, called "Tom", which calls this new template:

{{template:Silly-Mod
| Name = Tom
| Age = 61
| Existing-Row = Bob
}}

In a perfect world. this would return:

  • Tom
  • 61
  • Medium
  • 175

And the "Silly" table would have 5 rows (one for Bob, Alice, Ted, George, and Tom).

Instead, I get an HTML 500 error when I try to save the page for "Tom", I have a permanent message on the "Special:Cargo Tables" page, which says "Note: One or more of these tables are currently being populated, via the job queue." and the table "Silly" never goes above 4 rows.

I'm sure I'm just doing something stupid here, but I really don't know how to proceed. Thanks for being so responsive! --Nuada99 (talk) 03:46, 1 December 2017 (UTC)

Alright. That seems like it should work... if you take out the #cargo_query calls from the template, does it work? Yaron Koren (talk) 03:35, 4 December 2017 (UTC)
I think I've resolved this by storing Silly-Mod into a new table, and just dynamically pulling data into the display portion of the template (via queries). After some thought, I didn't really need to store the re-used row data a second time. Thanks so much for your help, and great job with Cargo! I'm excited by all the possibilities of it. -Nuada99 (talk) 18:47, 4 December 2017 (UTC)

Max Columns?[edit]

Is there a known maximum number of columns that a single table can hold in Cargo? I see that the max in MySQL is 4096, and I'm nowhere near that, but I am trying to build a table with around 450 columns, and I'm getting an HTTP 500 error when I try to build the table. I can send the template file with the fields, but I don't want to post it here, because it's HUGE. --Nuada99 (talk) 23:29, 6 December 2017 (UTC)

That's very large! I don't think I've heard of anyone else creating a table with anywhere near that many columns, so you may be in uncharted territory here. I would try creating the table via the command-line script cargoRecreateData.php, if you can - you at least won't get a server timeout. Yaron Koren (talk) 02:44, 7 December 2017 (UTC)
So, I tried the command line script (php cargoRecreateData.php --table Monster), and received a 'Template does not exist' error. Now, when I try to view the Special:CargoTables page, I see an HTML 500 error.
To try to correct this, I tried commenting out all of the Cargo extension bits in LocalSettings.php, and then restarting mysqld, and running Maintenance.php, then un-commenting the Cargo back in, but the problem still exists. I also rebooted the server, which still didn't fix the issue.
So, I deleted the template which was trying to create that table, but I'm not sure how to delete the table itself, or manually clear the issue with Special:CargoTables.
In the meantime, I've tried creating small test tables, which still works.
Sorry to be such a hassle. Still trying to wrap my head around this. Any suggestions for getting a clean start with Cargo? At this point, there is no table data I feel a need to preserve. --Nuada99 (talk) 14:49, 7 December 2017 (UTC)
Restarting MySQL, Apache etc. won't make any difference - the problem is just that some operations are taking too long to do. Just to be clear: is the page that's timing out just "Special:CargoTables", or "Special:CargoTables/Monster" (or whatever the table name is)? I'm guessing it's the latter. As for getting rid of the bad data - there are probably better ways to do it, but you can always go the "cargo_tables" DB table and delete either just the "Monster" row, or all rows. Yaron Koren (talk) 15:24, 7 December 2017 (UTC)
Both "Special:CargoTables", or "Special:CargoTables/Monster" are displaying an html 500 error when I load them. (See [1]). I'll try deleting the rows from "cargo_tables" in the DB when I get some time. Hopefully that will let me ease into this without any lingering weirdness getting in the way. --Nuada99 (talk) 16:26, 7 December 2017 (UTC)
Ah, I didn't know that this was a public wiki. And I thought that maybe "Monster" was just a code name, given that this is a monster-sized template, but no, it's a template for a monster. :) This is really a massive template, and the fact that it declares a 450-field table is maybe not even the most relevant aspect of it - it contains a whole lot of logic, including lots of transclusions, which may be slowing things way down. I still have no idea why Special:CargoTables isn't working, but it doesn't look like a timeout (my first guess) - I would recommend this addition to see the actual error message. Yaron Koren (talk) 19:01, 7 December 2017 (UTC)

Cant get Cargo to use custom DB name[edit]

I've defined

  • $wgCargoDBtype
  • $wgCargoDBserver
  • $wgCargoDBname
  • $wgCargoDBuser
  • $wgCargoDBpassword

in LocalSettings.php

But Cargo still creates the tables in the mediawiki DB Can someone tell me what am I doing wrong?

Maybe you included those lines before, instead of after, the inclusion of Cargo. Maybe existing tables now need to be recreated. Maybe you've mistyped the custom database details and Cargo defaults to the MW database. These are all just guesses! Jonathan3 (talk) 22:54, 9 December 2017 (UTC)

Cargo and $wgRunJobsAsync[edit]

Manual:Job_queue and Manual:$wgRunJobsAsync state that $wgRunJobsAsync is now set to false by default. Is there an ideal setting when running Cargo? Thanks Jonathan3 (talk) 22:50, 9 December 2017 (UTC)

Oh, that's interesting. It shouldn't matter in theory, although there have indeed been problems for some people using "async", which I assume is why they changed the default back, so turning it off seems safer. Yaron Koren (talk) 00:56, 11 December 2017 (UTC)