Skip to content

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

Open
teebot opened this issue Mar 10, 2020 · 143 comments · May be fixed by prisma/prisma-engines#4208
Open

Geolocation/Spatial types support #1798

teebot opened this issue Mar 10, 2020 · 143 comments · May be fixed by prisma/prisma-engines#4208
Labels
domain/client Issue in the "Client" domain: Prisma Client, Prisma Studio etc. domain/psl Issue in the "PSL" domain: Prisma Schema Language domain/schema Issue in the "Schema" domain: Prisma Schema, Introspection, Migrations etc. kind/feature A request for a new feature. topic: geo topic: native database types

Comments

@teebot
Copy link

teebot commented Mar 10, 2020

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 :

  • Have a schema annotation @@spatial so that migrate would create a geometry type in postGIS, a geojson field in mongo etc.
  • generate could type this to a geoJSON definition
  • client would translate queries to St_FromGeoJSON in postGIS, leave the geoJSON as is in Mongo

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.

@janpio janpio added kind/feature A request for a new feature. topic: native database types labels Mar 10, 2020
@zifahm
Copy link

zifahm commented Mar 27, 2020

@teebot is there a workaround for this?

@teebot
Copy link
Author

teebot commented Mar 27, 2020

Yes!

  • When you introspect geometry types will be marked as strings in your schema
  • Exclude these types from your crud queries
  • when you need them make a raw query and expose as geojson then json parse the string

@zifahm
Copy link

zifahm commented Mar 27, 2020

I would love to see and example @teebot :)

@pantharshit00 pantharshit00 changed the title Spatial types support Geolocation/Spatial types support Jun 25, 2020
@tctrautman
Copy link

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.)

@johanmic
Copy link

@tctrautman
cant speak on actual support in the schema annotation but the real issue is the lack of custom types (i.e geography)
hopefully its covered by this #446
which is marked in the next milestone (2.4.0) https://github.com/prisma/prisma/milestone/41

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

@tctrautman
Copy link

Thanks @jaywalklabs -- this is really helpful.

@thebiglabasky
Copy link

Hi,
Supporting GIS types is not currently planned. We have indeed started picking up native types as mentioned above here #446 but we first focus on the most common types which don't require specific client-side mapping yet.
The roadmap is available at https://pris.ly/roadmap if you want to have an overview of the topics we're tackling and ideas about our timelines

@benknab
Copy link

benknab commented Aug 12, 2020

@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?

@thebiglabasky
Copy link

@bkiac Interesting, that's good context, thanks.
I don't believe we have ironed out the details at this point, but I will surface that idea to the team.

@Hebilicious
Copy link

Hebilicious commented Aug 22, 2020

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.
I really like @bkiac idea and it would be nice to take it further by allowing "manual" migrations where custom logic can be written.
Consider a greenfield project that wants to use postgres+postgis with node. In the official example, there's a prisma/posgis/express example repository. In this case, having the ability to use prisma migrate instead of manually running sql scripts + prisma introspect would make prisma way more valuable imo.
It would be neat if we had the ability to generate custom migrations (with a Laravel-like syntax) :

//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).

@thebiglabasky
Copy link

Thanks for these details!
We are currently rethinking migrate to eventually push it out of the experimental state. At this time, the leading idea is to allow to customize a generated migration. This could serve one aspect of the problem. @albertoperdomo is focusing on migrate with the team and they're looking at how native types will be handled there so there will definitely progress in the right direction in the coming weeks/month.

@l4j3b
Copy link

l4j3b commented Oct 30, 2020

+1

1 similar comment
@theswerd
Copy link

+1

@albertoperdomo albertoperdomo added the domain/schema Issue in the "Schema" domain: Prisma Schema, Introspection, Migrations etc. label Feb 3, 2021
@gilneto8
Copy link

gilneto8 commented Feb 5, 2021

Will this be rolling out soon?

@Jolg42
Copy link
Contributor

Jolg42 commented Feb 8, 2021

You can now try 2.16.0

@@ignore & Unsupported makes it possible to use PostGIS for example, as $raw queries, and Migrate will not drop these columns.

Release Notes:
https://github.com/prisma/prisma/releases/tag/2.16.0

Also check:
#4531 (comment)

Daniel created a PostGIS example using $raw queries with the client and using latest Migrate Preview features:
https://github.com/2color/interest-points/blob/master/prisma/schema.prisma

Truncated example:

model berlin_pois {
  gid    Int                      @id @default(autoincrement())
  osm_id String?                  @db.VarChar(10)
  code   Int?                     @db.SmallInt
  fclass String?                  @db.VarChar(28)
  name   String?                  @db.VarChar(100)
  geom   Unsupported("geometry")?
  @@index([geom], name: "berlin_poi_idx")
  @@map("berlin-pois")
  @@ignore
}

model spatial_ref_sys {
  srid      Int     @id
  auth_name String? @db.VarChar(256)
  auth_srid Int?
  srtext    String? @db.VarChar(2048)
  proj4text String? @db.VarChar(2048)
  @@ignore
}

We are looking for feedback and are planning to release Prisma Migrate out of Preview soon 😄

@benjamintd
Copy link

benjamintd commented Feb 10, 2021

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:

  • on create/update, all geometry types can be parametrized as geojson, and the middleware would convert them using ST_GeomFromGeoJSON
  • on read, all geometry types are read as geojson using ST_AsGeoJSON.

Can this be done with the current middleware API, or do we have to resort to raw queries ?

@Jolg42
Copy link
Contributor

Jolg42 commented Feb 10, 2021

Hi @benjamintd

So you'll need to use raw queries since Unsupported fields are not surfaced in the client at all.

@baba43
Copy link

baba43 commented Feb 22, 2021

I have a POINT field in my MySQL db that gets annotated by Unsupported("point").

Is there any simple way or workaround that would allow prisma to at least fetch this field in regular queries?

@Jolg42
Copy link
Contributor

Jolg42 commented Feb 23, 2021

@baba43 you'll need to use the $raw queries, someone opened a related feature request #5683

@anaibol
Copy link

anaibol commented Nov 18, 2024

+1

@acidjazz
Copy link

+1, excited to see more progress on the PR!

@mc-luisg
Copy link

+1

1 similar comment
@Em1lT
Copy link

Em1lT commented Nov 27, 2024

+1

@mateoghione99
Copy link

+11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

@AntonyBaasan
Copy link

+1

@bnhovde
Copy link

bnhovde commented Jan 13, 2025

+1

@altarrok
Copy link

altarrok commented Jan 13, 2025

To people commenting "+1" or asking for updates repeatedly: this is accomplishing nothing, except annoying both the maintainers and the people who subscribed to this issue in order to get actual updates in due time. Just stop.

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..

@SarenT
Copy link

SarenT commented Jan 13, 2025

To people commenting "+1" or asking for updates repeatedly: this is accomplishing nothing, except annoying both the maintainers and the people who subscribed to this issue in order to get actual updates in due time. Just stop.

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.

@bobber205
Copy link

+1

@altarrok
Copy link

To people commenting "+1" or asking for updates repeatedly: this is accomplishing nothing, except annoying both the maintainers and the people who subscribed to this issue in order to get actual updates in due time. Just stop.

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.

Complaints about +1 spams are at least easy to disregard.

no, they aren't. that's where your "copy opponent's move" type of thinking fails..
Also, a person that thinks someone will stop +1 ing through their comment, would be more open to stop spamming, by reading another comment about why they are wrong. So my criticism is positive, yours is negative.

@mateoghione99
Copy link

We are tired of waiting 5 years for this issue to be resolved. Everyone on planet earth should write +1

@bobber205
Copy link

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.

@LeulAria
Copy link

LeulAria commented Jan 13, 2025

God this issue still exist how can i unsubscribe 🤣🤣🤣🤣 use kysely guys just use kysely

@bobber205
Copy link

God this issue still exist how can i unsubscribe 🤣🤣🤣🤣 use kysely guys just use kysely

Image

@SarenT
Copy link

SarenT commented Jan 13, 2025

To people commenting "+1" or asking for updates repeatedly: this is accomplishing nothing, except annoying both the maintainers and the people who subscribed to this issue in order to get actual updates in due time. Just stop.

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.

Complaints about +1 spams are at least easy to disregard.

no, they aren't. that's where your "copy opponent's move" type of thinking fails.. Also, a person that thinks someone will stop +1 ing through their comment, would be more open to stop spamming, by reading another comment about why they are wrong. So my criticism is positive, yours is negative.

Your comment is not clearly written and I won't bother to put too much effort to understand it to prove a point.

@SarenT
Copy link

SarenT commented Jan 13, 2025

-1, this feature is not that important (tragedy of commons)

@mateoghione99
Copy link

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.

@Ehbraheem
Copy link

Another missing feature in Prisma 😀

@sovetski
Copy link

sovetski commented Apr 3, 2025

Any update 5 years later please?...

@persiklover
Copy link

+1

@heyyfurqan
Copy link

Still missing this feature in prisma :)

@acanturk1
Copy link

+1

3 similar comments
@emwadde
Copy link

emwadde commented May 8, 2025

+1

@vladislavbogomolov
Copy link

+1

@QuantumGlitch
Copy link

+1

@andrewpurcell
Copy link

+1. would love some way to at least query spatial fields without resorting to $queryRaw.

@garretteklof
Copy link

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 ✨

@acidjazz
Copy link

Nonsense! one day my grandkids will use prisma Geo/Spatial support even though i switch to drizzle a LONG time ago.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain/client Issue in the "Client" domain: Prisma Client, Prisma Studio etc. domain/psl Issue in the "PSL" domain: Prisma Schema Language domain/schema Issue in the "Schema" domain: Prisma Schema, Introspection, Migrations etc. kind/feature A request for a new feature. topic: geo topic: native database types
Projects
None yet
Development

Successfully merging a pull request may close this issue.