Closed pbrisbin closed 9 months ago
And note that this is not a problem compiling graphula itself, it only breaks with a particular use-case. We might want to add a test case for the now-broken way we use KeySource
on none-safe-to-insert entities.
Done in #73
As of lts-21, the version of persistent present needs
SafeToInsert
to useinsert
. This serves as witness that the entity in fact uses an auto-increment key and so is "safe to insert [without explicit key]". Entities where this is not true must useinsertKey
and supply the key.insertKey
, of course, does not enforceSafeToInsert
. So safe.In Graphula, we have only the single
insert
member in theMonadGraphulaFrontend
typeclass. And it always requires (our compatibility type for)SafeToInsert
. This is because it takes aMaybe Key
argument and usesPersist.insert
onNothing
(orPersist.insertKey
onJust
).Up until lts-21, this constraint was a no-op and we in fact created cases where we use Graphula on entities that aren't safe to insert. Since we always supplied a
Just key
to ourinsert
for these cases (based onKeySource
), it all worked. But once that constraint becomes actually-enforced, they no longer type check.At this point, in order to depend on newer persistent and keep up with the latest LTS, we think we need to expand the type-class to include
insertKey
, which will be used bynodeKeyed
(notnode
), and then we can migrate these non-compiling use-cases.This calls into question the overall design of
insert
, with itsMaybe
argument,node
andKeySource
, etc -- as we seem to be diverging with how persistent is tackling a similar design space. If it turns out we can't avoid a major version bump, we might consider taking larger liberties here.However, if we can do this as a minor version bump that would be preferred. It could be possible if we give
insertKey
some default. But we have to do that in a way that doesn't keep theSafeToInsert
constraint onnodeKeyed
when used. (For example,insertKey = insert . Just
won't work.) :thinking:/cc @tomcarste