sequelize-transparent-cache icon indicating copy to clipboard operation
sequelize-transparent-cache copied to clipboard

Included models not returning with timestamps

Open JesalR opened this issue 6 years ago • 6 comments

I'm currently using sequelize-transparent-cache and redis to retrieve data using the following call

let quiz = await Quiz.cache().findByPk(quizId, { include: [ 'nodes', 'results' ], where: { categoryId: categoryIds } });

On first call (grabbing direct from the DB) this is fine. However, on subsequent calls (from the cache), the included nodes or results do not have any of the timestamps. Our JSON schema serializer (fast-json-stringify) then complains, because the schema requires the createdAt and updatedAt keys.

The data inside redis does infact have the timestamps on the included associations, but it seems it's not being returned back to the instances

JesalR avatar Oct 18 '19 13:10 JesalR

Thanks for report! Please update to latest version, I just published fix. Let me know how it goes!

DanielHreben avatar Oct 18 '19 14:10 DanielHreben

It returns the dates fine now, but they're no longer of date type anymore. They come out as strings, I imagine because the instance is put back together using raw: true?

Either way, it's something we can work around on our end temporarily

Cheers

JesalR avatar Oct 18 '19 15:10 JesalR

Yea, you right. I updated tests so now they catching this problem and fixed it by recursively setting timestamp fields. Try 2.2.0 version and let me know how it goes!

DanielHreben avatar Oct 20 '19 07:10 DanielHreben

Thanks for the quick update. I'm actually having an issue now that's causing crashes

TypeError: instance.get is not a function at Object.keys.forEach.key (/node_modules/sequelize-transparent-cache/src/cache/util.js:43:39)

This seems to happen on an instance which has a jsonb column, but I imagine it will also happen on an instance with an array column. The recursive function restoreTimestamps treats object or array members of the instance as if they themselves are always instances too.

This isn't always true and so causes the above error to be thrown

JesalR avatar Oct 21 '19 14:10 JesalR

Shit. I wrapped it into try\catch blocks to quickly fix the issue and published 2.2.1. I will switch tests to postgres, cover and fix this case properly later.

DanielHreben avatar Oct 22 '19 12:10 DanielHreben

Cool, the hotfix seems to work for us. Thanks for the quick updates!

JesalR avatar Oct 22 '19 12:10 JesalR