Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't put middleware higher than Dexie Cloud #2047

Closed
tylermercer opened this issue Jul 31, 2024 · 4 comments
Closed

Can't put middleware higher than Dexie Cloud #2047

tylermercer opened this issue Jul 31, 2024 · 4 comments

Comments

@tylermercer
Copy link

I have a custom middleware that I want to run only on user operations and not on operations that are performed by the Dexie Cloud addon. E.g. if the user creates an entity in the app, this middleware should be invoked. When that entity gets synced to another device, it should not be, even though it's being created there (by dexie-cloud-addon) for the first time.

I tried to set the level param of my custom middleware to 2 as was done in this POC of using dexie-encrypted with Dexie Cloud, but it doesn't seem to be working; the middleware is still called on operations that are triggered by Dexie Cloud.

What am I missing?

@dfahlander
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

That makes sense! Thanks for your help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants