IntersectMBO / IntersectMBO/lsm-tree
[BUG] `matchSessions` is brittle if sessions use different `HasFS` instances
- Dominant language
- Haskell
- Stars
- 53
- Forks
- 17
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 4
Description
https://github.com/IntersectMBO/lsm-tree/blob/eb8d04cf7f32935e7894fe6d223363c262388cf4/src/Database/LSMTree/Internal.hs#L1709-L1739
`matchSessions` checks whether a non-empty set of tables all have the same session by checking that the session roots (i.e., file paths) are the same. Recall that because of file locking, there can only be one open session at any given time for a specific directory. However, this really only works nicely if all sessions are using the same `HasFS` instance. Each session has its own `HasFS` instance (with its own mount point if it is the real file system), and the implementations of the `HasFS` instances might be different entirely (some could be the real file system, some could be simulations). So in general, `HasFS ` instances (and therefore sessions) can not be uniquely identified by the session root.
In practice, all sessions will be using the same `HasFS` instance, but it's not guaranteed to be so. Ideally, we'd be able to compare the `HasFS` instances as well, but it's hard (if not impossible) to compare `HasFS` instances because they are records of functions. Maybe we could get away with giving each `HasFS` instance an approximately unique identifier (like wall clock time) to use a basis for comparisons. If something like this is not achievable, then we should at least mention the brittleness in the documentation of `matchSessions` and possibly in the public API.
One could also muse about whether it would be fine for the union's input tables to have different sessions and pick one of the sessions arbitrarily for the output table. I can imagine that this would open a whole other can of warms, so maybe it's best to restrict interaction between sessions as much as possible.
Contributor guide
Assessment
This issue has not been assessed yet.