-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Geolocation/Spatial types support #1798
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
Comments
@teebot is there a workaround for this? |
Yes!
|
I would love to see and example @teebot :) |
Hi all. First time poster here, coming to Prisma from the Redwood community. Thanks for the work you all are doing -- I've really enjoyed working with Prisma 2 and Prisma migrate so far. Is there a place I can check to see where geo support falls on the Prisma roadmap or, if not, is that something you could speak to here? (Apologies if I missed this in my initial search.) |
@tctrautman once thats in im hoping that you dont have to fight against migrate that its trying to remove columns thats not in the schema etc. running raw queries is really not an issue for me personally |
Thanks @jaywalklabs -- this is really helpful. |
Hi, |
@thebiglabasky My only real issue with unsupported GIS types is being unable to use the migration tool. Are you planning to / is it feasible to implement a type or function to flag a field as any type so the migration tool can ignore it? |
@bkiac Interesting, that's good context, thanks. |
I believe supporting GIS types is extremely important, especially given the fact that all the databases that prisma support/plan to support has a way to work with GIS :
@thebiglabasky While I understand that prioritising things can be hard, what I would really like to see in the meantime is improvements when it comes to unhandled cases like this one. //CustomMigration.ts
export const up = async () => {
//Raw SQL logic that creates tables/columns/install extensions etc
}
export const down = async () => {
//Raw SQL logic that tear down things created by "up"
} This would generate a migration folder with a README.md, schema.prisma and steps.json, and would add the migration to the lockfile. In the data-model the created columns with unsupported types would simply appear with a special annotation/flag. While this is a little bit rough, at least it would allow the handling of a lot of edge cases and make prisma migrate a much more versatile tool. This would make prisma + prisma migrate a much better standalone tool (no need to manually run sql scripts/introspect anymore). Having first class geometry/postGIS support would be much better in this example, but implementing something like this in the meantime seems much easier, and would be quite valuable (for example it gives you a way to add postgres functions using a similar manual migration approach). |
Thanks for these details! |
+1 |
1 similar comment
+1 |
Will this be rolling out soon? |
You can now try
Release Notes: Also check: Daniel created a PostGIS example using Truncated example:
We are looking for feedback and are planning to release Prisma Migrate out of Preview soon 😄 |
Hi! Thanks for the example using the unsupported types. Is it possible to use a middleware to handle these unsupported types? A common use case would be:
Can this be done with the current middleware API, or do we have to resort to raw queries ? |
Hi @benjamintd So you'll need to use raw queries since |
I have a Is there any simple way or workaround that would allow prisma to at least fetch this field in regular queries? |
+1 |
+1, excited to see more progress on the PR! |
+1 |
1 similar comment
+1 |
+11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 |
+1 |
+1 |
by initiating a discussion unrelated to this issue, on this issue, you are contributing to the spam. As 5+ comments have been made about this discussion. Please don't respond and accept that +1 ers will +1, and feel free to open a new issue about this. +1 spams are at least easy to disregard, when you open a discussion it is not disregarded until some thought has been given to it. You are pouring oil to the flame.. |
by initiating a discussion unrelated to this issue, on this issue, you are contributing to the spam. As 6+ comments have been made about this discussion. Please don't respond and accept that people will complain about the "+1" spam, and feel free to open a new issue about this. Complaints about +1 spams are at least easy to disregard. When you open a discussion about the complaints, it is not disregarded until some thought has been given to it. You are pouring oil on the fire. |
+1 |
no, they aren't. that's where your "copy opponent's move" type of thinking fails.. |
We are tired of waiting 5 years for this issue to be resolved. Everyone on planet earth should write +1 |
A global pandemic came and went w/o a basic feature of this -- I know some PRs have been submitted I think at least to address this but havent' been merged -- what is the official stance of the team on on this? It's not like it's been Abandoned far from it. |
God this issue still exist how can i unsubscribe 🤣🤣🤣🤣 use kysely guys just use kysely |
Your comment is not clearly written and I won't bother to put too much effort to understand it to prove a point. |
-1, this feature is not that important (tragedy of commons) |
The truth is that the person who made the post has retired from work. Let’s hope that their great-grandchildren, at the very least, will be able to use Prisma with geolocation. |
Another missing feature in Prisma 😀 |
Any update 5 years later please?... |
+1 |
Still missing this feature in prisma :) |
+1 |
3 similar comments
+1 |
+1 |
+1 |
+1. would love some way to at least query spatial fields without resorting to $queryRaw. |
folks.. I hate to play pallbearer to this tragic news.. but, I've been on this thread and other threads, just like this for what feels (and may, quite possibly be) millennias (and before most of you were born, to boot, mind you!) I'm sorry; this is simply: not happening. We must, accept. And in that may we, finally... ✨ heal ✨ |
Nonsense! one day my grandkids will use prisma Geo/Spatial support even though i switch to drizzle a LONG time ago. |
Uh oh!
There was an error while loading. Please reload this page.
Currently prisma2 does not support spatial types. This is not exactly an edge case since according to google 9% of sql files on github carry out spatial queries.
I was thinking how that feature could work but it’s probably a bit naive given I don’t know the implementation details of prisma2 :
The rationale behind this is that you basically want migrate to create the right spatial type in your db, currently schema/code-first does not work and introspect detects spatial as a string. Yuo also want client to perform CRUD on tables containing spatial types, currently CRUD fails if the spatial type is in the select so a
.raw
request is the only workaround.The text was updated successfully, but these errors were encountered: