Extension talk:External Data/Archive 2017 to 2018

Can't use array of data as array of strings
I use #get_db_data for fetching an array of strings T12U from a database. It works just fine since I'm able to show the data using  , e.g.: M,M,D,D,H,Y,M,Y,. I prepared a template Time unit for conversion these data to a more readable form: However, the following code   shows nothing. Though the template itself works fine, e.g.   produces min. What's wrong? --176.104.0.186 07:25, 16 January 2013 (UTC)


 * The issue is just that #for_external_table can't handle templates very well; it's something I need to look into. Yaron Koren (talk) 16:23, 16 January 2013 (UTC)

Stricter Parameter in New Version causes much work
I didn't find any hints in the release notes (maybe I didn't look proberly`?)

empty MySQL-access password doesn't work anymore
In older Version was it possible to access MySQL with empty user password (what was OK for a complete internal WIKI in an environment where all participants have access on script level) Now I had to add a password in MySQL and LocalSettings.php.

Changes in get_db_data-syntax
following once worked

Now it this has to be changed in

Otherwise you'd get

"Unknown column 'NNVN' in 'field list'"

with

"SELECT VN_NN_Name,NN_VN=NN_VN_Name,Company,Phone FROM `PersonAdresse` WHERE `VN_NN_Name` LIKE 'G%'

Means, "VNNN=" vanished and "NNVN=" is misinterpreted, therefore: Second Topic seams to reopen "Issue with parameters that contain '_'" --Hk sup (talk) 09:46, 23 January 2013 (UTC)
 * no space in combination with "=" and ","
 * no internal names with underscore "_"
 * I'll have to change a lot :-(


 * Hi - I can't think of any change to the External Data code that would have caused either issue. Perhaps the real cause in both cases was an upgrade of MediaWiki itself? Yaron Koren (talk) 13:25, 23 January 2013 (UTC)


 * Simply true, a new MediaWiki needed new External Data Extension. But who has to be addressed for this problem? I updated to the newest version of mediawiki and semantic media bundle and expected less massive change in behaviour. Was my old way to use no mysql password and get_db_data-syntax that far away from the intended standard?
 * --Hk sup (talk) 11:00, 24 January 2013 (UTC)


 * Well, the values of "data=" are meant to be on a single line, yes - although support for putting them on separate lines could probably easily be added to the code. As for underscores in the values, "A_B" and "A B" are two different things (unless it's part of a wiki page name), so I'm not surprised that it doesn't work to use the wrong one. And connecting to MySQL with an empty password - unfortunately I know nothing about that; the External Data code just calls MediaWiki's own database-connection code. You might ask on the mediawiki-l mailing list, or #mediawiki IRC channel. Yaron Koren (talk) 13:59, 24 January 2013 (UTC)


 * Thanks for the clarification --Hk sup (talk) 14:41, 24 January 2013 (UTC)

variable names breaks queries
I'm not sure in what version things broke, however I just upgraded to 1.5 (from 1.3.3 I believe) and all my previous db queries stopped working. This is because I prefix and postfix my variable names so that I don't get collisions.

In 1.5 if in your data= section you have data=username=user_name,realname=user_real_name,email=user_email everything is peachy. data=username_postfix=user_name,realname=user_real_name,email=user_email is also cool with an underscore on the first variable data=username-postfix=user_name,realname=user_real_name,email=user_email or a dash on the first variable data=username_postfix=user_name,realname_postfix=user_real_name,email=user_email data=username-postfix=user_name,realname-postfix=user_real_name,email=user_email Doing it on the second or 3rd variable however, breaks the query. You'll get an error for "EDUtils:SearchDB" db error "1056: Unknown column 'realname' in 'field list' (192.168.1.1)".

What is also interesting is that in the output of the SQL query, the first field 'user_name' will not have a variable assigned to it, only the 2nd+ do.

No changes were made to the wiki itself, all these queries and templates used to work, it looks like the error is in the parsing code for variables, which must have changed.

--Finlay Beaton (talk) 19:26, 1 February 2013 (UTC)


 * I downgraded External Data to 1.4.3 and the problem still occurs.
 * I then downgraded to 1.2.2 (the only tar I had lying around of pre-git days) and the problem does not occur and everything works as expected. I'll dig around and see if I have 1.3.3 lying around and use that but until it's fixed I can't run >1.4 series.
 * --Finlay Beaton (talk) 19:35, 1 February 2013 (UTC)


 * Yes, I'm aware of that problem - it was just discovered on the SMW mailing list two days ago, by coincidence. It's due to a change that was made in version 1.4.2. I hope to have it fixed soon. Yaron Koren (talk) 19:46, 1 February 2013 (UTC)

Why get_db_data does not contain GROUP BY?
Why get_db_data does not contain GROUP BY? Are any plans to introduce this option? --178.214.207.74 13:31, 8 February 2013 (UTC)


 * No strong reason - it just didn't seem that helpful, I guess, to get a breakdown of values without actually getting the values themselves. Yaron Koren (talk) 03:33, 13 February 2013 (UTC)

Max column characters
I am having an unknown issue with only one column where the name is 32 characters long. Could the length of the column name be the issue? --Dgennaro 17:34, 8 March 2013 (UTC)


 * Hi - it's possible, although I don't think there's anything in the External Data code that restricts the column name length... Yaron Koren (talk) 20:31, 8 March 2013 (UTC)

Error: Incomplete information for this database ID
I installed the extension without any problem. I created a new database in the same SQL database as MediaWiki is. Placed below information in LocalSettings.php: $edgDBServer['employee-db'] = "localhost"; $edgDBServerType['employee-db'] = "mysql"; $edgDBName['employee-db'] = "test"; $edgDBUser['employee-db'] = "testuser"; $edgDBPass['employee-db'] = "testpassword"; Then I placed following code in one of the wikipages to test (with the syntax before and after): get_db_data: db=employee-db The firstname is the name of one of the columns in the table I try to get data from. The information I recieve is following "Error: Incomplete information for this database ID." I am not sure what the problem might be! Any ideas?
 * from=agenter
 * data=firstname=firstname

Never mind. It was me who was dumb. I placed database settings above the add extension line which caused the problem.

Table not update directly
I use the External Data extension to display a table of users which works just fine. But if I add a new user or delete a user I need to press edit and then save to update the table. How can I get around that problem?


 * You don't need to save the page - you just need to refresh/purge it. You can do that by adding "action=purge" to the URL; or, conversely, you can just wait about 24 hours, for the page cache to expire. Yaron Koren (talk) 21:07, 13 March 2013 (UTC)

I saw some information regarding the cache. Some managed to get a workaround installing a extension MagicNoCache but that didn´t solved it for me. I made a change yesterday at 4:00 PM and today at 08:00 AM it still hadn´t made the change. Is there a possibility to minimize the cache time for that extension only? I changed the $wgParserCacheExpireTime in DefaultSettings.php (found in includes) to 60 seconds as a workaround. Best would be to have the change only for External Data extension if that would have been possible.


 * Hi - for MagicNoCache to work, you need to add the " __NOCACHE__ " tag to that page - did you try that? That's actually the best way to ensure that External Data calls are always up-to-date. Yaron Koren (talk) 14:10, 14 March 2013 (UTC)

I missed that part, thank a lot!