[Wikidata-bugs] [Maniphest] [Changed CC] T85181: Investigate design public API, possibly using MQL
JanZerebecki added a subscriber: JanZerebecki. JanZerebecki added a comment. Would exposing Gremlin in some form publicly be an option? TASK DETAIL https://phabricator.wikimedia.org/T85181 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JanZerebecki Cc: GWicke, Smalyshev, JanZerebecki, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T85159: Deploy a Wikidata complex query service into production
Lydia_Pintscher added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T85159 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Aklapper, RobLa-WMF, Krenair, jkroll, Smalyshev, Wikidata-bugs, aude, GWicke, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T84923: Reliable publish / subscribe event bus
Lydia_Pintscher added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T84923 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: GWicke, aaron, JanZerebecki, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, RobH, aude, Manybubbles, daniel, mark, Joe ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T85105: Add css class to the links that are using language fallback as label
Lydia_Pintscher added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T85105 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Aklapper, Sjoerddebruin, Multichill, Wikidata-bugs, aude, Gryllida, Shizhao, Arrbee, Quiddity ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T85004: Use CSS instead of jQuery for wb-claim-name position animation
Lydia_Pintscher added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T85004 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Aklapper, Krinkle, Wikidata-bugs, aude, GWicke ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T85173: Investigate Titan supernode issues
Lydia_Pintscher added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T85173 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Manybubbles, Lydia_Pintscher Cc: Aklapper, Manybubbles, jkroll, Smalyshev, Wikidata-bugs, aude, GWicke, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T85181: Investigate design public API, possibly using MQL
Lydia_Pintscher added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T85181 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: GWicke, Smalyshev, JanZerebecki, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T85174: Validate Java 8 package
Lydia_Pintscher added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T85174 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Manybubbles, Lydia_Pintscher Cc: Aklapper, Manybubbles, jkroll, Smalyshev, Wikidata-bugs, aude, GWicke, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T85133: Introduce setting to allow import of entities from XML dumps.
Lydia_Pintscher added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T85133 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Aklapper, daniel, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T78693: Tool to set up entries in the sites table, to allow sitelinks to be created
Lydia_Pintscher added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T78693 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Aklapper, despens, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T77281: Prepare for Wikidata Integration on Commons
Lydia_Pintscher added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T77281 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Aklapper, Lydia_Pintscher, Wikidata-bugs, aude, Fabrice_Florin, Gilles, Tgr ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T76009: upload wizard with structured data
Lydia_Pintscher added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T76009 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: JanZerebecki, Gilles, Aklapper, MingleTerminator, Wikidata-bugs, aude, Fabrice_Florin, Tgr ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T76373: Evaluate Titan as graph storage/query engine for Wikidata Query service
Manybubbles added a comment. I think mixed indexes as documented in http://s3.thinkaurelius.com/docs/titan/current/indexes.html#index-mixed should help here, as they support efficient matching on an arbitrary combination of attributes, along with advanced range and full text queries. They do require an indexing backend like Elasticsearch to be configured. Nik, is there an Elasticsearch setup we could use, or would it be reasonably easy to spin up a new one? I'd spin up a new one - probably just on a single node. I think in the long run we probably can run this on the production search cluster but for now lets keep it off just in case it does something stupid. I can put together some puppet changes to put a single node elasticsearch instance on einsteinium. For Date, I wonder if support can't be added to Titan, since Elastic AFAIK supports dates. It sure does. They are parsed and formatted automatically but amount to a java long since epoch under the hood. As @GWicke said that means they can't reach back until the big bang. If instead of dealing in dates we dealt in _seconds_ since epoch we could reach back to the big bang so long as current estimates are right to within an order of magnitude. Instead of 292 million years ago we'd have 292 billion years ago. Also, while Java can support negative years, right now the import does not support them since the Java parser fails to properly parse them. If we're moving to Java 8, there are better date APIs AFAIR, so maybe they allow to handle it properly. Elasticsearch is based on Joda Time which can handle negative years just fine. It can't handle negative years that far back though. I've filed an issue https://github.com/elasticsearch/elasticsearch/issues/9048 for it but I imagine we'll be on our own. I believe they are getting infinite precision numbers at some point but the kind of dates we handle are probably best stored in floating point instead. For SET it won't be more complex to maintain, probably, but I'm not sure if the lookups would be fast enough. I could create an additional field for that and see how it behaves, and then we could drop the field that is not needed. Elasticsearch totally supports sets. Like, so supports. We use them for stuff like hastemplate and incategory. Have a look at the dump http://en.wikipedia.org/wiki/Nikola_Tesla?action=cirrusdump for a page. Lucene has native support for sets of strings, sorta. Its a very leaky abstraction around pretending that they are one big string with junk tokens between them. The junk tokens prevent phase searches from spanning multiple values in the set. Looking at mixed indexes I wonder how they are backed to Elasticsearch. Lucene/Elasticsearch pretty much indexes everything independently and then ANDs the results of traversing multiple indexes together to get the answer. That deserves some looking into. TASK DETAIL https://phabricator.wikimedia.org/T76373 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, Manybubbles Cc: Smalyshev, Manybubbles, GWicke, JanZerebecki, aude, Lydia_Pintscher, Eloquence, aaron, jkroll, Wikidata-bugs, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T76373: Evaluate Titan as graph storage/query engine for Wikidata Query service
GWicke added a comment. In https://phabricator.wikimedia.org/T76373#941917, @Manybubbles wrote: I'd spin up a new one - probably just on a single node. I think in the long run we probably can run this on the production search cluster but for now lets keep it off just in case it does something stupid. I can put together some puppet changes to put a single node elasticsearch instance on einsteinium. Awesome, that would be great! I think storage is not very fast there (disks IIRC), but maybe the 64G of memory will compensate. For Date, I wonder if support can't be added to Titan, since Elastic AFAIK supports dates. It sure does. They are parsed and formatted automatically but amount to a java long since epoch under the hood. As @GWicke said that means they can't reach back until the big bang. If instead of dealing in dates we dealt in _seconds_ since epoch we could reach back to the big bang so long as current estimates are right to within an order of magnitude. Instead of 292 million years ago we'd have 292 billion years ago. Seconds wouldn't actually work, but years will, especially if represented as a double. The big bang represented as years comfortably fits into the 52-bit mantissa of a double, so we wouldn't get weird rounding artifacts like reading back 13.834520923424352345234523 billion years after storing 13.8. But we'd have plenty of range for other cosmic dates. Elasticsearch is based on Joda Time which can handle negative years just fine. It can't handle negative years that far back though. I've filed an issue https://github.com/elasticsearch/elasticsearch/issues/9048 for it but I imagine we'll be on our own. I believe they are getting infinite precision numbers at some point but the kind of dates we handle are probably best stored in floating point instead. Parsing out the year portion of an ISO 8601 timestamp in the API frontend is not all that hard, so we could just go ahead and index on a double representation of that in Titan. For dates within the long cut-off, we can also convert that to long (or double), and store that in a finer-grained index. We'll then need to switch between year-based indexing and finer-grained indexing in the front-end after looking at a string representation of a timestamp in the query. Looking at mixed indexes I wonder how they are backed to Elasticsearch. Lucene/Elasticsearch pretty much indexes everything independently and then ANDs the results of traversing multiple indexes together to get the answer. That deserves some looking into. The documentation says that it efficiently supports multi-predicate queries on the same index, so I assume that it sends off all predicates to elasticsearch at once, and lets it deal with efficiently ANDing. TASK DETAIL https://phabricator.wikimedia.org/T76373 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, GWicke Cc: Smalyshev, Manybubbles, GWicke, JanZerebecki, aude, Lydia_Pintscher, Eloquence, aaron, jkroll, Wikidata-bugs, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T85181: Investigate design public API, possibly using MQL
Smalyshev added a comment. @janZerebecki Gremlin is basically shell access, since it can run arbitrary Java code. So we can have it for internal purposes, but we need frontend API since we probably won't be comfortable with giving everybody shell access, and sanitizing Gremlin probably would be more complex than handling any simpler language. TASK DETAIL https://phabricator.wikimedia.org/T85181 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: GWicke, Smalyshev, JanZerebecki, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T76373: Evaluate Titan as graph storage/query engine for Wikidata Query service
Smalyshev added a comment. Elasticsearch totally supports sets. Right, but Titan unfortunately doesn't support mixed indexes on SET properties. I would assume it's not a hard limitation but rather them not getting to implementing it yet. The mixed index type support is very limited now http://s3.thinkaurelius.com/docs/titan/0.5.2/search-predicates.html#mixeddatatypes - for one, they don't support booleans, for example. TASK DETAIL https://phabricator.wikimedia.org/T76373 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: Smalyshev, Manybubbles, GWicke, JanZerebecki, aude, Lydia_Pintscher, Eloquence, aaron, jkroll, Wikidata-bugs, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T76699: Lost connection to MariaDB server during query
coren moved this task to Waiting for information on the Tool-Labs workboard. TASK DETAIL https://phabricator.wikimedia.org/T76699 WORKBOARD https://phabricator.wikimedia.org/project/board/539/ REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: coren Cc: Aklapper, Magnus, Husky, coren, Lokal_Profil, Steinsplitter, Danilo, Wikidata-bugs, aude, jayvdb, scfc ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Reassigned] T76699: Lost connection to MariaDB server during query
coren reassigned this task from coren to Springle. coren added a subscriber: Springle. coren added a comment. I see the problem occuring intermitently, but I am unable to reproduce it myself. @springle: do you have insight on what could be going on / has changed? TASK DETAIL https://phabricator.wikimedia.org/T76699 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Springle, coren Cc: Aklapper, Magnus, Husky, coren, Lokal_Profil, Steinsplitter, Danilo, Springle, Wikidata-bugs, aude, jayvdb, scfc ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T84923: Reliable publish / subscribe event bus
GWicke added a comment. In https://phabricator.wikimedia.org/T84923#940155, @JanZerebecki wrote: The nature of these event type candidates is such that they are changes with a log existing at the provider. Wikidata might be the exeception here. Most other events are not available at the provider in a reliable manner. The actual data can be pulled by the consumer from the provider; Is there an API for this already? I think the only thing here where pub/sub brings anything worth is the event that new changes are available to decrease latency of updates. Which means only ever one event in queue for all consumers, as new events contain all information of the previous ones. A major benefit of an event stream is reliability, performance and simplicity. The same generic client (using websockets for example) can be used to consume a variety of events. Queues like Kafka are optimized for the use case and perform really well at high request volumes. As an example, we are currently processing about 50k messages/second (request logs) with two Kafka nodes. I know that most other events are lower volume than this, but it's good to have headroom in the system. How is the job queue currently not reliable? For one, it uses redis for storage, which only supports async master/slave replication and has limited options for durability. Async replication means that you are likely to lose messages in a fail-over. Limited durability means that you lose messages on power loss. It also does not support multiple consumers for each event (no pub/sub), which results in fairly static coupling of producer and consumer. You need to create a new job per consumer. Finally, the job runners are doing all kinds of processing instead of pure event delivery. As mis-behaving jobs compete with others for resources, this makes them less reliable than a pure event delivery system would be. TASK DETAIL https://phabricator.wikimedia.org/T84923 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: GWicke Cc: GWicke, aaron, JanZerebecki, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, RobH, aude, Manybubbles, daniel, mark, Joe ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T85181: Investigate design public API, possibly using MQL
mobrovac added a subscriber: mobrovac. TASK DETAIL https://phabricator.wikimedia.org/T85181 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mobrovac Cc: GWicke, Smalyshev, JanZerebecki, mobrovac, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T84923: Reliable publish / subscribe event bus
mobrovac added a subscriber: mobrovac. TASK DETAIL https://phabricator.wikimedia.org/T84923 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mobrovac Cc: GWicke, aaron, JanZerebecki, mobrovac, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, RobH, aude, Manybubbles, daniel, mark, Joe ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T85181: Investigate design public API, possibly using MQL
GWicke added a comment. In https://phabricator.wikimedia.org/T85181#940893, @Smalyshev wrote: Are we considering supporting WDQ API mini-language as the option for the queries or it's not a viable option? The problem I see with the WDQ language is the need to perform error-prone custom quoting and serialization in clients. For numeric identifiers this might not be so bad, but strings, dates etc will need escaping. JSON basically avoids these issues by letting the JSON serializer / parser deal with it. We could still compile a more human-friendly DSL like the WDQ language to JSON, but forcing every client to deal with custom escaping and serialization issues does not sound like a great idea for a public API. TASK DETAIL https://phabricator.wikimedia.org/T85181 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: GWicke Cc: GWicke, Smalyshev, JanZerebecki, mobrovac, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T76373: Evaluate Titan as graph storage/query engine for Wikidata Query service
GWicke added a comment. Another fun article for dates: http://en.wikipedia.org/wiki/Timeline_of_the_far_future TASK DETAIL https://phabricator.wikimedia.org/T76373 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, GWicke Cc: Smalyshev, Manybubbles, GWicke, JanZerebecki, aude, Lydia_Pintscher, Eloquence, aaron, jkroll, Wikidata-bugs, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T85181: Investigate design public API, possibly using MQL
Smalyshev added a comment. Agreed, format like JSON would be much better since everybody knows how to handle it. TASK DETAIL https://phabricator.wikimedia.org/T85181 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: GWicke, Smalyshev, JanZerebecki, mobrovac, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T85181: Investigate design public API, possibly using MQL
mobrovac added a comment. How about using the Sirent JSON https://github.com/kevinswiber/siren format? It aims at giving a complete description of a resource, complete with URIs. Granted, it's more verbose than other solutions, but it could be used also to create different pre- and post-parsers for other formats (MQL, WDQ, etc.) due to its completeness. TASK DETAIL https://phabricator.wikimedia.org/T85181 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mobrovac Cc: GWicke, Smalyshev, JanZerebecki, mobrovac, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T85252: Edit buttons are getting cached, although their visibility depend on user rights
hoo created this task. hoo added subscribers: hoo, Lydia_Pintscher, daniel, aude. hoo added a project: MediaWiki-extensions-WikibaseRepository. TASK DESCRIPTION Title says it all: We cache the edit buttons on entity pages, although their visibility depend on user rights. Eg. if an IP purges an edit=autoconfirmed item the edit buttons will be gone for everybody. TASK DETAIL https://phabricator.wikimedia.org/T85252 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hoo Cc: Aklapper, hoo, Lydia_Pintscher, daniel, aude, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T85252: Edit buttons are getting cached, although their visibility depends on user rights
hoo changed the title from Edit buttons are getting cached, although their visibility depend on user rights to Edit buttons are getting cached, although their visibility depends on user rights. TASK DETAIL https://phabricator.wikimedia.org/T85252 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hoo Cc: Aklapper, hoo, Lydia_Pintscher, daniel, aude, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T85252: Edit buttons are getting cached, although their visibility depends on user rights
JohnLewis added subscribers: Wikidata-bugs, JohnLewis. JohnLewis added a comment. Added wikidata-bugs as a CC as adding Wikidata as a project isn't possible for some reason (@aklapper) TASK DETAIL https://phabricator.wikimedia.org/T85252 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JohnLewis Cc: Aklapper, hoo, Lydia_Pintscher, daniel, aude, Wikidata-bugs, JohnLewis ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T76373: Evaluate Titan as graph storage/query engine for Wikidata Query service
Manybubbles added a comment. I was using that! TASK DETAIL https://phabricator.wikimedia.org/T76373 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, Manybubbles Cc: Smalyshev, Manybubbles, GWicke, JanZerebecki, aude, Lydia_Pintscher, Eloquence, aaron, jkroll, Wikidata-bugs, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T85252: Edit buttons are getting cached, although their visibility depends on user rights
Lazowik added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T85252 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lazowik Cc: Aklapper, hoo, Lydia_Pintscher, daniel, aude, Wikidata-bugs, JohnLewis ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T77816: Improve CMD handling of multiple information templates
Tgr closed this task as Resolved. Tgr added a comment. Mingle duplicate of the three related bugs, which have been fixed. TASK DETAIL https://phabricator.wikimedia.org/T77816 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Tgr Cc: Aklapper, Wikidata-bugs, Fabrice_Florin, Gilles, Tgr ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T85257: Properties linking to Commons pages are not updated automatically when the page is moved
SJu created this task. SJu added a subscriber: SJu. SJu added projects: MediaWiki-extensions-WikibaseClient, MediaWiki-extensions-WikibaseRepository. TASK DESCRIPTION The page names in the property P373 (commons category) are not updated automatically and immediately when the target Commons pages is renamed/moved. Properties P935, P1472, P1612 and maybe also P18, P10, P51, P443 and P990 linking to Commons may be also affected. TASK DETAIL https://phabricator.wikimedia.org/T85257 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: SJu Cc: Aklapper, SJu, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T85259: Reciprocal Wikidata properties don't work really as reciprocal
SJu created this task. SJu added subscribers: Aklapper, SJu. SJu added a project: MediaWiki-extensions-WikibaseRepository. TASK DESCRIPTION Most of Wikidata properties are reciprocal by their essence. Some of them symmetrically, some of them asymmetrically, some of them 1:1, some 1:n, n:1 or n:n. However, they are really not built as reciprocal and don't really work as reciprocal. TASK DETAIL https://phabricator.wikimedia.org/T85259 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: SJu Cc: Aklapper, SJu, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T85181: Investigate design public API, possibly using MQL
GWicke edited the task description. TASK DETAIL https://phabricator.wikimedia.org/T85181 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: GWicke Cc: GWicke, Smalyshev, JanZerebecki, mobrovac, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T85181: Investigate design public API, possibly using MQL
JeroenDeDauw added a subscriber: JeroenDeDauw. TASK DETAIL https://phabricator.wikimedia.org/T85181 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JeroenDeDauw Cc: GWicke, Smalyshev, JanZerebecki, mobrovac, JeroenDeDauw, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T85181: Investigate design public API, possibly using MQL
JeroenDeDauw added a comment. Has any thought been put into how to combine this with the plans the Wikidata team has for queries? TASK DETAIL https://phabricator.wikimedia.org/T85181 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JeroenDeDauw Cc: GWicke, Smalyshev, JanZerebecki, mobrovac, JeroenDeDauw, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T74430: Re-implement uniqueness constraint in a consistent and efficient way
JeroenDeDauw added a subscriber: JeroenDeDauw. JeroenDeDauw added a comment. Calling this fingerprint is confusing, since we already use that word for a different concept. (Do point out how evil this is.) I like the general idea proposed here. TASK DETAIL https://phabricator.wikimedia.org/T74430 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JeroenDeDauw Cc: Tobi_WMDE_SW, daniel, Wikidata-bugs, JeroenDeDauw, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
