hoo added a comment.
I talked to Gabriel about plans to obsolete link tables and he told me, that
there are no immediate plans to replace local link tables (which includes this
table). Due to this, I will pick this up in the next days if @daniel is ok with
that.
TASK DETAIL
https://phabrica
hoo added a comment.
In that case I think we should pick this up soon. If my above analysis is
correct and per the IRC discussion I had with @daniel yesterday, I don't think
is very hard to do.
First step is to stop using `eu_touched`, then stop updating (touching) it and
finally we can drop i
jcrespo added a subscriber: jcrespo.
jcrespo added a comment.
As per @hoo request, I am sharing my own opinion here:
This is blocking ROW based replication application, which should be rolled in
soon. In my own opinion (database-focused) I think wikidata updates (this is
one of them) are the wo
hoo added a comment.
We talked about this on IRC some more and came to the conclusion that it would
probably work without `eu_touched`.
It's probably not worth implementing that, as dependency graphs are upcoming
anyway.
TASK DETAIL
https://phabricator.wikimedia.org/T124737
EMAIL PREFERENC
hoo added a comment.
In https://phabricator.wikimedia.org/T124737#1966530, @daniel wrote:
> > I don't see why that would be the case. It seems to me you are under the
> > misconception that we purge caches for individual languages, but we don't
> > (and can't).
>
> True, we don't right now. But
daniel added a comment.
Btw: conceptually, when tracking dependencies, we need to track the identity of
resource that depends. eu_cache_key would provide this, eu_touched is a hacky
way to get around that requirement.
TASK DETAIL
https://phabricator.wikimedia.org/T124737
EMAIL PREFERENCES
daniel added a comment.
> I don't see why that would be the case. It seems to me you are under the
> misconception that we purge caches for individual languages, but we don't
> (and can't).
True, we don't right now. But that is being worked on. Then again, once we have
proper dependency tracki
hoo added a comment.
> So, as far as I can see, we can get rid of eu_touched only if we replace it
> with eu_cache_key. That would effectively mean tracking usage for each target
> language separately.
I don't see why that would be the case. It seems to me you are under the
misconception that
daniel added a comment.
Note that our primary use case for usage tracking is purging the parser cache.
So we need to track usages for every rendered version of a page that gets
stored in the parser cache. When a page is changed or not, and what the
revision timestamp is, is really not relevant.
