Breaking change: extension will return Promise<{ result: Model, isCached: boolean }> vs. Promise<Model>

[pmosconi]

Hi @yxx4c ,
in the same codebase (monorepo), I am not always using the redis extension: it depends on environment (e.g. not use it in dev) and application (e.g. if it mostly writes, the cache instead of helping just introduces additional latency and overhead).
With this scenario, it is critical that what comes from the database through Prisma is not dependent upon the extension being present or not.
For sure, there are other use cases where it is important to have additional information about the cache behavior, not to mention tests.

I quickly tried to implement another extension to chain to prisma-extension-redis that just returns the content of the result property, but I didn't succeed (maybe I didn't try hard enough).
If you have a solution that can be chained to the extension, be it another one, or something else at the Prisma client level, I'd be glad to implement it.

If this is not possible, I suggest to add a "Prisma Compatibility" switch in the cache configuration that, when set to true, just return the result content.

What do you think?

[yxx4c]

Hi @pmosconi,

Back when I was working on this change, I did think of these scenarios, so the only workaround I thought of at that time was to create a dummy extension that creates a similar result as prisma-extension-redis.
Example

{
result: Model
}

Maybe with some configurable pseudo values.
Example

{
result: Model
isCached: boolean // always set to a static value based on config during extension init
}

I will let you know if I think of something better, please let me know if this process helps your need or you absolutely need it to work the other way, by normalizing the output back to its original form!

[pmosconi]

Hi @yxx4c ,
what you propose is certainly a solution, but it can have quite a big impact because it still requires the code to be modified for each Prisma operation.
I'd rather use a compatibility flag that enables the user to opt in to the new behavior: this can then be done gradually leaving older applications untouched and, in my opinion, providing a better developer experience.

[yxx4c]

Hi @pmosconi

I understand your concerns better right now, I think we can add a flag for this and should be pretty easy, maybe getting typescript to behave properly might take some time, let's try to do this after we merge the new changes.

[pmosconi]

Hi @yxx4c ,
sounds really good for me: let me know if I can help.
I forked v2 so I'm no hurry!
Thanks for your understanding