As a user of Opaleye, I feel that Opalaye's public API is missing a number of features/niceties that are required by most people using the library in a largish project. The number of separate projects trying to close these gaps seem to strengthen this point:
Based on the discussion at silkapp/girella#9, specifically Tom's approval in that thread, this is an effort to build consensus around features that Opaleye's users would like to see in the core library directly. Of course, these features should not compromise general principles that @tomjaguarpaw has specifically mentioned:
- Type-safety
- Composability
- In-built support for DB transactions
- In-built support for connection-pooling
- In-built support for logging
- Default logging with an ability to over-ride with user-supplied function
- Helper functions to query a table based on primary key (will require TH?) and return Haskell-types (not PG types)
- Custom data-types for commonly used primary keys, eg.
UserId,OrderId, etc. - Easier way to do partial row updates based on Haskell types
- Add raw SQL escape hatch
- Support for JSON functions and operators in Postgres
- [Support for tstzrange](Support for tstzrange)
- In-built support for migrations
- Support for IN clause with sub-selects
Please feel free to comment below with your thoughts about the proposed features. I volunteer to moderate & collate the discussion periodically.
Thanks, this is a good start.
(I didn't get the ping, by the way. I only saw this via the issue on silk-opaleye. Perhaps mentions on gists work differently?)