section 4.8 states "The trans service does not support a callback parameter as the mqlread service does", this is outdated since the api states it can and it can:
http://www.freebase.com/view/guid/9202a8c04000641f8000000007628edf
The trans example could use some improvement too since it is digging out "unrelated" documents from the store. It would be more informative and more consistent to get documents on the band "the police"
Query to get guid's for articles and images
{
"article" : [
{
"guid" : [
{}
],
"id" : null
}
],
"id" : "/en/the_police",
"image" : [
{
"guid" : [
{}
],
"id" : null
}
],
"type" : "/common/topic"
}
Query to get the article (function foo can format result without using a proxy):
http://www.freebase.com/api/trans/raw/guid/9202a8c04000641f800000000006df25?callback=foo
Query to get the image (you can use this as the source property of the image element)
http://www.freebase.com/api/trans/image_thumb/guid/9202a8c04000641f8000000003c18713?maxwidth=300&maxheight=300
Note: you cannot make an image bigger than the origional with maxwith and maxheight
Discussions on 4. Metaweb Read Services
-
-
-
-
-
-
If you try a GET query that has the URL length go above about 4000 characters, you will get a "Transient Error" from the Freebase API. The API should really return an error of "URL too long, use POST".
Even though it isn't mentioned, the MQL Read does support POST. I recommend using it instead of GET.
-
-
-
I can't seem to find anything documenting the lifetime of a cursor value returned from the MQL read service.
Do cursors persist between query sessions? If so, for how long? Could I run a query to obtain some data, save the cursor, and then continue where I left off a few days later?
Thanks.
-
Hi rath,
The short answer is that cursors are stateless. The kinds of things that invalidate cursors are cursor format changes that happen with database software upgrades; but they're safe against time, session ends, or reuse.
If you're trying to use a cursor, and get a BADCURSOR reply from the server back, and there wasn't a database software upgrade, there are two possible explanations:
(a) a bug - cursors are complicated and underused, and it's quite possible that you're running into a bug.
(b) you've changed the query in some small way, so the cursor checksum that encodes the constraint around the cursor as well as the cursor text no longer matches the constraint you're actually submitting along with the cursor.
If it's an intermittent problem, it's likely (a); if it fails reliably, it's likely (b).
-
-

