https://www.prisma.io/ logo
Join Slack
Powered by
Has anybody found a nicer way to return Unsupporte...
# orm-help
s
Has anybody found a nicer way to return Unsupported fields from the Prisma client? I understand that integrating postGIS with all its complexity is a large ticket item, but returning a Point field as a String sounds like an easy temporary solution for many - I don’t want to give up on Point/Polygon types and store them in the wrong format, just so Prisma can pull it through as a string. It’s mentioned that you cannot get these fields back from the generated client, even as a basic findMany return, and when using a raw query I’m stuck having to cast to a TEXT type within the psql query otherwise Prisma quaint fails to convert the postgres point to String also? https://www.prisma.io/docs/concepts/components/prisma-schema/features-without-psl-equivalent/#unsupported-field-types Maybe I’ve missed a basic technique, but right now I’ve have to leave behind any where/orderBy niceness to get all values back from a select, and it’s looking extremely hacky for production. Any suggestions to improve on this are highly appreciated! PostGIS support which I assume will resolve this limitation for geo types: https://github.com/prisma/prisma/issues/2789
Examples of how I’ve done it so far:
Copy code
model RandomModel {
  id Int @id @default(autoincrement())

  point Unsupported("point")?
  geometry Unsupported("polygon")?
}
Hacky solution to handle the business critical filters I’ve now lost due to the raw query:
Copy code
const records = await context.prisma.$queryRaw<RandomModel[]>`
      SELECT 
        id, updated_at, point::TEXT, geometry::TEXT
      FROM 
        "RandomModel"
        ${
          updatedGte
            ? Prisma.sql`WHERE updated_at >= ${updatedGte}`
            : Prisma.empty
        }
        ${
          orderingUpdated
            ? orderingUpdated === 'asc'
              ? Prisma.sql`ORDER BY updated_at asc`
              : Prisma.sql`ORDER BY updated_at desc`
            : Prisma.empty
        }
        `
j
Unsupported really is just for Migrations support - not Prisma Client.
The problem behind this is that with "just" casting to a string, we already need to do a lot of the support work to really implement the feature. How would you define in PSL that this unsupported should be returned as a String? What about updating or writing these fields? How do we even detect a 
point
on that side of our code?
What you could do is open an issue though for your use case - basically having something that is more than 
Unsupported
(with no Client support) to something new that has some Client support in a specific form, and then give us examples how this would look like (PSL and Prisma Client API) so we can think if this is worth implementing before we get to properly support GIS.
What do you mean with "business critical filters" though? Not sure I am following that message.
s
Hey @janpio thanks for getting back to me, hopefully my message didn’t come across as too greedy, overall Prisma is doing a nice job when mixed with nexus. I think in the conversion between the client and underlying quaint library is where this complexity will be - I’ll take a look now at the codebase and try to mock up an example, I think the key might be to allow the user to take responsibility in what the client tries to cast to:
Copy code
randomLocation String @Unsupported("point")?
I’ll open a ticket after some thinking.. Business critical filters - I meant the filters such as where/order etc that we are using for this specific project, I can no longer opt-in to using the client to generate these (passed all the way from nexus-prisma), so it’d be nice to have more granular “intercepts” so I can target just to override the selection of fields, but let the client handle the rest. This is a feature in itself though
👍 1
j
That makes sense, and I like the idea that is behind your PSL syntax suggestion. (Could also be the other way around: 
randomLocation @Unsupported("point") @client.cast/fallback(string)
or something like that) Btw: Don't go to deep into our implementation details, we can do that when the issue exists and we know what the goals are.
s
I found that you already had a very similar issue so I didn’t want to create yet another one, I added some more info here: https://github.com/prisma/prisma/issues/5683#issuecomment-1064012856 Let me know if I can help somehow!
j
Good catch, thanks.
(Made small changes to the comment as there were weird control characters)
🙌 1
3 Views
Open in Slack
PreviousNext
Powered by