Yeah, when it's "the only way you can get the results", you may have no option but to use it. "This should not be done" is just a //should//, and applies only if you have another better option. Here, you don't.
When someone asks how, don't answer how not; it will not solve the problem. A solution is a solution, and if you can't find a better method for someone else, don't say not to do so without a very good reason (such as a foreseeable breakage), because people want to solve problems rather than not staying in a puddle of more problems. Do propose a different path if you oppose one [1]. [1] https://www.mediawiki.org/wiki/Wikimedia_Cloud_Services_team/Team_Social_Norms#-_Do_propose_a_different_path_if_you_oppose_one Zhuyifei1999 2018-01-18 12:16 GMT-06:00 Daniel Schwen <li...@schwen.de>: > A lot of things were not really foreseeable, like not being able to create > user tables on replica servers. This killed projects. You better heed the > comment of "this should not be done". Otherwise you'll end up in the same > spot as me. It was unforeseeable that that ability would be taken away, > many people used it (it was the only way to get the desired results), yet > "we shouldn't have done it"... Don't fall into the same trap. > > On Thu, Jan 18, 2018 at 10:28 AM YiFei <zhuyifei1...@gmail.com> wrote: > >> Well, you are free to suggest a better advice. In the case of shards >> splitting into different servers, Quarry will have to implement a server / >> database selector [1], and processing data from two databases in a single >> query may not be possible at all, like currently in the case of tools-db >> and replicas, where all inter-host joins must happen in application space. >> >> In any case, the question is how to do cross-wiki joins properly instead >> of emulating them with temporary variables, which what I have suggested may >> be how one would do it properly, when it works at least //in the >> foreseeable future//. (Yes, changing is a possibility but it’s not >> currently foreseeable whether or when it will happen.) >> >> [1] https://phabricator.wikimedia.org/T76466 >> >> Zhuyifei1999 >> >> On Thu, Jan 18, 2018 at 9:39 AM Brad Jorsch (Anomie) < >> bjor...@wikimedia.org> wrote: >> >>> On Wed, Jan 17, 2018 at 5:50 PM, YiFei <zhuyifei1...@gmail.com> wrote: >>> >>>> SELECT ... FROM `<database>`.`<table>`, like in >>>> https://quarry.wmflabs.org/query/24212. This should work in the >>>> foreseeable future, during which all the replica databases are accessible >>>> on the same server. >>>> >>> >>> This is bad advice. Just last week[1] one of our DBAs warned this list >>> that that ability is not guaranteed or supported, and changing that is >>> indeed a possibility. >>> >>> [1]: https://lists.wikimedia.org/pipermail/cloud/2018-January/ >>> 000169.html >>> >>> >>> -- >>> Brad Jorsch (Anomie) >>> Senior Software Engineer >>> Wikimedia Foundation >>> _______________________________________________ >>> Wikimedia Cloud Services mailing list >>> Cloud@lists.wikimedia.org (formerly lab...@lists.wikimedia.org) >>> https://lists.wikimedia.org/mailman/listinfo/cloud >> >> _______________________________________________ >> Wikimedia Cloud Services mailing list >> Cloud@lists.wikimedia.org (formerly lab...@lists.wikimedia.org) >> https://lists.wikimedia.org/mailman/listinfo/cloud > > > _______________________________________________ > Wikimedia Cloud Services mailing list > Cloud@lists.wikimedia.org (formerly lab...@lists.wikimedia.org) > https://lists.wikimedia.org/mailman/listinfo/cloud >
_______________________________________________ Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly lab...@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud
