Delete by query

[coder]

@cryptokid @alex, what is the recommended opposite of coreservices_addEventSync?

If we keep the tables pruned on a regular basis (every 30 mins or so), we have zero issues. However, in situations in which the sync gets behind (e.g. we stop testing our apps for the day), the syncs get waaaaaaay behind again (as expected).

Clearing the tables in those situations still works, it just takes a while to “catch up”. Can we simply “destroy” our sync subscription and recreate it?

[cryptokid]

There is a way to do it, I don’t remember the exact name now. It could be something that starts with remove_

[alex]

There is a way to do it, I don’t remember the exact name now. It could be something that starts with remove_

Can you try this.

[coder]

@alex

This seems to work ok on my end with a lot of results - but it may take some time before it’s finished. It may make sense to have an upgraded server to handle all of these tasks.

So, I get that the upgraded server is a potential solution to the issue, but what factors account for the inconsistency in syncs staying up to date?

I ask because, I’ve run this setup for the last several days without issue. All syncs stay up to date, and even when I stop and let things build up, the server has caught back up just fine.

However, this morning, I stopped and cleared everything, restarted and it refuses to get within 10 minutes of live data.

Again, I realize “better server equals better performance”. But what would make all 4 of my current syncs stay consistently behind? Also, how are they all delayed at basically the “same” rate? What is the root sync-er doing (or not doing) to cause such a thing? It seems more artificially induced than circumstantial.

[alex]

I’m not sure, could you run tests or give examples/timestamps of this consistent delay? Could be due to queuing.

[coder]

@alex

could you run tests or give examples/timestamps of this consistent delay

It’s not necessarily “testable”, simply “observable”. Usually I’ll purge the system and it will catch back up. However, when it doesn’t catch back up, it seems that each individual sync (say BSC, ETH, AVAX, MATIC) gets delayed by the same amount.

For instance, currently, all syncs are showing between 20:01:00 and 20:03:00 UTC as their max value. Are all values technically streaming from the same background source? At the very least, I don’t see how BSC and ETH are “slowed” to the same times.

I’m sure Moralis has some “optimizations” going on in the background, but I can’t imagine how that would/should affect syncs from unrelated chains.

Not sure what I’m missing.