On Thu, Jan 18, 2018 at 12:28 PM, YiFei wrote:
> 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.)
>
Not being able to create user tables on the replicas wasn't foreseeable. It
was possibl
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
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
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 repl
On Wed, Jan 17, 2018 at 5:50 PM, YiFei wrote:
> SELECT ... FROM ``.``, 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 DB
SELECT ... FROM ``.``, 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.
Zhuyifei1999
2018-01-17 14:11 GMT-06:00 Federico Leva (Nemo) :
> I usually use bash or python scrips to que
