search

haskell-beam / beam

A type-safe, non-TH Haskell SQL library and ORM
https://haskell-beam.github.io/beam/
581 stars 170 forks source link

Split into beam-postgres-core #462

Open srid opened 4 years ago

srid commented 4 years ago

I'm unable to use the Postgres types (like PgJSONB) in Reflex apps (common package of obelisk) because beam-postgres won't compile in GHCJS as it depends on postgresql, etc.

Unless I'm missing something, it seems to me that the only solution here is to move these types into a separate beam-postgres-core package.

What do you think @kmicklas ?

kmicklas commented 4 years ago

Hmm, my general inclination would be to say that your frontend shouldn't depend on the backend schema like that. However, I see how it can be convenient.

tathougies commented 4 years ago

I think this is a good idea. Someone at one point also was interested in a 'binary' PG backend, and it would be good to share code between the two.

mightybyte commented 2 years ago

Hmm, my general inclination would be to say that your frontend shouldn't depend on the backend schema like that. However, I see how it can be convenient.

I'd like to second the desire for this. I share beam types with the frontend pretty heavily in Zeus.

https://github.com/mightybyte/zeus/blob/master/common/src/Common/Types/BinaryCache.hs https://github.com/mightybyte/zeus/blob/5566e3244f1ab0cd245e4c36be315a5abddb5810/frontend/src/Frontend/AppState.hs#L124

I'm also very familiar with creating a separation between frontend and backend types. It's also a very useful design pattern. But I don't think the usefulness of either approach negates the value of the other. I happened to not be using Postgres-specific types in Zeus, but if I had I would have run into this problem.