eoin-obrien / prisma-extension-kysely

Drop down to raw SQL in Prisma without sacrificing type safety!
https://www.npmjs.com/package/prisma-extension-kysely
MIT License
207 stars 5 forks source link

CamelCasePlugin Support #29

Closed luap2703 closed 10 months ago

luap2703 commented 10 months ago

Is your feature request related to a problem? Please describe. Hi! First of all amazing plugin! Great work, we wanted to do the same and now are just using yours :)

Atm CamelCasePlugin does not correctly work. The returned items are still snake_case. I think it would be easily achievable to check if CamelCase Plugin is active and if yes, manually rewrap the result in the transformResult() function.

Normally the engine/driver would do it, but as thus this plugin is only used as query builder, it won't be done automatically.

Thank you and greetings from Germany! Paul

eoin-obrien commented 10 months ago

Hi! First of all amazing plugin! Great work, we wanted to do the same and now are just using yours :)

Danke schön! I'm delighted to know the plugin was useful for you. :)

Atm CamelCasePlugin does not correctly work. The returned items are still snake_case. I think it would be easily achievable to check if CamelCase Plugin is active and if yes, manually rewrap the result in the transformResult() function.

Normally the engine/driver would do it, but as thus this plugin is only used as query builder, it won't be done automatically.

This should be pretty straightforward to implement! I've taken a quick look at Kysely's plugin API, and unfortunately, we can't get a list of plugins from the Kysely object after it's been constructed, though we can add more with .withPlugin().

An additional caveat is that transformResult() takes a queryId parameter so the plugins can identify which query produced a result. This is managed internally by Kysely and doesn't seem to be straightforward to fetch or replace without replacing Kysely's query executor.

To me, the simplest workaround would be to pass the list of plugins to the kyselyExtension() function as well, so it can call transformResult() as appropriate. However, because of the above, I'd prefer not to implement a solution that could cause some plugins to fail silently!

Instead, it might be preferable to explicitly support the camel case plugin. For example:

const prisma = new PrismaClient().$extends(
  kyselyExtension({
    kysely: new Kysely<DB>({
      dialect: { /* ... */ },
    }),
    /* Defaults to false */
    camelCase: true,
  }),
);

This API is identical to what prisma-kysely exposes, so we can make sure that the generated types match the actual results. If we were to extend support to all of the CamelCasePluginOptions rather than just the default, then it would probably require a PR on that library too!

Does this seem like a good solution for your use case? If so, I should be able to get it coded up, documented and released swiftly!

mhaagens commented 10 months ago

Would love this feature as well!

eoin-obrien commented 10 months ago

This turned out to be a little more complex than I thought it would be at first glance, but it's pretty much ready to release as part of v2.0.0 of the extension! By hooking into Kysely's driver class, I've managed to enable support for all Kysely plugins, not just CamelCasePlugin. Keep an eye out for PR #37 being merged! Feel free to test it out in the meantime too.