Projections #173

gregwebs opened this Issue Oct 12, 2013 · 4 comments


None yet
3 participants

gregwebs commented Oct 12, 2013

My thought process now is that the user should declare the projections available.

Then we need an overloaded lens (mkFields from lens) to use a simple name instead of a projection-overloaded name. Alternatively we could wait until 7.10 or try to start using vinyl.


gregwebs commented Oct 27, 2013

I looked into dependent-map, but that makes everything a Maybe. A DMap lets us have a map of field names to values, where unlike a normal Map the values can have different types corresponding to their keys.
The only problem with DMap is that to retrieve a field we now do a lookup that returns a Maybe. But we already know based on the query what fields are available, so this is a little unsatisfactory.

Groundhog returns tuples from projections, but the problem is there is no longer a corresponding field name. So you could have a projected tuple of (Text, Text, Text) that would be easy to screw up.

We could instead use an extensible records package such as vinyl. However, I don't know how we can give back a type for our projections. Instead all functions operating on projections would be duck-typed based on the field. This could work if we stick with labels that are record-prefixed as persistent does now. Vinyl adds a lens dependency and I believe it is required for writing duck-typed functions.
A big downside of vinyl is that for a function using many record fields, the type signatures will start getting unwieldy. This is also true of using some kine of Has typeclass.

dependent-map has simple type signatures, integrates well with persistent, and does not add other dependencies. The price we pay is that every access is a Maybe.


snoyberg commented Jul 19, 2015

Closing out old issues, please reopen if still relevant

@snoyberg snoyberg closed this Jul 19, 2015

This seems like it should still be relevant, can someone with the right permissions reopen it?


gregwebs commented Oct 2, 2015

We prefer to use tithing issues for bugs or features that are being actively worked on

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment