Can't put middleware higher than Dexie Cloud

[tylermercer]

Can't put middleware higher than Dexie Cloud

[dfahlander]

The level param will only order the middleware differently to be called before or after other middlewares. There is no way to generically jump over another middleware since the down-level (or next) middleware has to be called to eventually reach the lowest level.

The sync engine does not origin from within a middleware. Middleware is there to track mutations and other things though. But I think you should be able to detect whether an operation was initiated by the user or from a sync operation. If trans.disableChangeTracking is true (that property is not typed so you'd have to // @ts-ignore it), it means that all the operations being performed are results from a sync operation and not locally performed.

[tylermercer]

If trans.disableChangeTracking is true (that property is not typed so you'd have to // @ts-ignore it), it means that all the operations being performed are results from a sync operation and not locally performed.

Neat! I was wondering if such a property existed but didn't notice that one.

I tried that just now and it seems to work, except for a case that I can't seem to reproduce, which I saw right at the beginning of my testing, where that property was falsy for an insertion that originated from dexie-cloud-addon.

Are there any cases where an entity is added by the dexie-cloud-addon but it doesn't set disabledChangeTracking to true? 🤔

[dfahlander]

Are there any cases where an entity is added by the dexie-cloud-addon but it doesn't set disabledChangeTracking to true? 🤔

Yes when storing dexie-cloud data in tables starting with $ in their name ($logins, $baserevs etc), then it does not need to set this property because those tables aren't tracked. But any change in synced application defined tables shall for sure have this property set when being updated.

[tylermercer]

That makes sense! Thanks for your help.