You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
but this type is a lie and the function will throw an error if called with a non-local state. Is there any reason why createCheckpointAndClose shouldn't be part of the abstract AcidState interface? This would make it easier to write backend-generic testing code.
It would also avoid the need for downcast/acidSubState etc.. Should we leave them in for backwards compatibility, as we don't currently offer another way to create a LocalState/RemoteState directly? Or should we offer alternative functions that construct the underlying sub-states in a type-safe way, and remove the dynamically-typed stuff altogether?
The text was updated successfully, but these errors were encountered:
I know createCheckpointAndClose was added as an after thought. That might explain why it is not part of the interface. Or maybe there was some reason why it was only appropriate for the local backend. But if there was a reason, I don't know what it was.
There is a question as to what createCheckpointAndClose should do in the remote case. I don't see any reason in principle that the remote interface couldn't support it, but that would require extending the protocol.
I've not done much with the remote interface and it is rather untested, so I'm not terribly keen to put a lot of effort into it. Thus I'd rather make the remote implementation do a non-atomic checkpoint before closing the state, and document that createCheckpointAndClose is backend-dependent.
At the moment
Data.Acid.Local
hasbut this type is a lie and the function will throw an error if called with a non-local state. Is there any reason why
createCheckpointAndClose
shouldn't be part of the abstractAcidState
interface? This would make it easier to write backend-generic testing code.It would also avoid the need for
downcast
/acidSubState
etc.. Should we leave them in for backwards compatibility, as we don't currently offer another way to create aLocalState
/RemoteState
directly? Or should we offer alternative functions that construct the underlying sub-states in a type-safe way, and remove the dynamically-typed stuff altogether?The text was updated successfully, but these errors were encountered: