No, neither table would have unqiueness constraints (besides the primary
keys).
2013/7/29 Sean Pringle <springle(a)wikimedia.org>
On Tue, Jul 23, 2013 at 1:42 AM, Denny Vrandečić <
denny.vrandecic(a)wikimedia.de> wrote:
* EntityUsage: one table per client. It has two columns, one with the
pageId and one with the entityId, indexed on both columns (and one column
with a pk, I guess, for OSC).
* Subscriptions: one table on the client. It has
two columns, one with
the
pageId and one with the siteId, indexed on both
columns (and one column
with a pk, I guess, for OSC).
EntityUsage is a potentially big table (something like pagelinks-size).
On a change on Wikidata, Wikidata consults the Subscriptions table, and
based on that it dispatches the changes to all clients listed there for a
given change. Then the client receives the changes and based on the
EntityUsage table performs the necessary updates.
We wanted to ask for input on this approach, and if you see problems or
improvements that we should put in.
Sounds OK to me.
Will (or could) pageId/entityId and pageId/siteId have unique constraints?
BR
Sean
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 |
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.