Page MenuHomePhabricator

gzipped page props
Open, LowPublic


The page props table allows us to store information associated with an article. It is limited in size

The Graph and Cite extension store gzipped content in references-1 and graph_specs fields that must be decoded via gzdecode before being useful.

As a side effect of storing these in page props they are accessible via the API.
Surfacing these in the API is a little confusing and arguably not useful.

For example:
on my local instance gives

This doesn't seem ideal. A few ideas

  • Allowing page props to have hints to explain how the client can make use of them
  • Allowing handlers in the API that are run before returning them so that the API response returns the page property as JSON for example
  • Allow certain page props to be hidden so they cannot be surfaced via the API

Event Timeline

Jdlrobson raised the priority of this task from to Needs Triage.
Jdlrobson updated the task description. (Show Details)
Jdlrobson added a subscriber: Jdlrobson.

This would be cool. The issue affects TemplateData too.

It would be nice if it worked with Special:PagesWithProp too, right now it just doesn't display binary or large values (see SpecialPagesWithProp::formatResult).

Fortunately we now have a "PageProps" class that manages access to the database table, thanks to @cicalese. The logic for handling gzipped pp_value fields (and maybe also values that are so huge that they span multiple rows) should be added there.

Although I note that the PageProps class doesn't cover SpecialPagesWithProp and ApiQueryPagesWithProp yet.

Graph ext uses its own api call to get pp_value unzipped. Also note that for format=json, it returns the value directly in the body of the response, not as a string. And I am sure @Jdlrobson and others would appreciate that instead of doing double-unserializing+double error check, JS clients can simply use the value directly. Please merge 258196 (T120380) to allow it for the core.

Hmm, interesting, but I think we can do this one step at a time. I imagine sending JSON-as-string (with all the escaped ") is still going to be better for performance than sending gzipped-JSON-as-string (with all the escaped binary data), assuming that the regular HTTP gzip compression kicks in as usual.

@matmarex in graph case, it is actually slower, because after being read from DB and unzipped, data has to be parsed into JSON, the specific graph's data retrieved (there could be multiple graphs per page, while user may only need one), and attached directly to the result's output.
If it was sent as a string, it would have had to be re-json-encoded, so it would be more cpu on the server, bigger payload, and more cpu on the client to double-decode it.

Let's leave aside the completely unrelated (and -2ed) T120380 here. It's not at all on-topic for this task, which is about the fact that trying to return binary data just doesn't work at all since Unicode normalization completely mangles it.

@Anomie, I disagree that it is unrelated. My understanding is that most usecases for binary pageprops is actually to store large json, and having a standard mechanism to get these pageprops would be good. Also, I think we should introduce a pageprops2 that does not limit it to 64KB, thus solving the related problem.

Jdforrester-WMF moved this task from To Triage to Freezer on the VisualEditor board.