Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API to manage database lifecycle and use handle outside of withDB bracket #5

Open
epoberezkin opened this issue Oct 28, 2024 · 2 comments
Assignees

Comments

@epoberezkin
Copy link

epoberezkin commented Oct 28, 2024

Currently there are two problems with the API:

  • you cannot open database once, when the server starts, and close on exit, instead it would need to be opened and closed on every operation - this is likely to be inefficient.
  • API doesn't differentiate between opening and creating database - this is error prone and it is better to manage in the application, where the application can potentially warn user about the missing database instead of creating a new one.

While the current withDB API needs to be preserved both for backwards compatibility and for simple testing, what is missing for production use is open/close/create APIs.

Happy to contribute if it's acceptable.

@epoberezkin
Copy link
Author

https://github.com/simplex-chat/rocksdb-haskell/pull/1/files?diff=split&w=1 - this does it for withDB, a similar thing can be done to withDBCF, but more stuff will need to be held in database handle probably.

Let me know if you want this PR

@jprupp
Copy link
Owner

jprupp commented Dec 9, 2024

The way I use it in production opens the database only once, and keeps the handle throughout the lifecycle of the application. The entire application is wrapped inside withDB or withDBCF. It prevents the user from shooting himself in the foot by leaving the lifecycle management of the database handle to the bracket. There's a Haskell language extension that can be used to prevent a database handle from escaping its context, called LinearTypes, but I haven't gotten around to experimenting with it.

What you seem to want to do with your change is to expose the underlying open/close functions to be used directly. Is that correct?

@jprupp jprupp self-assigned this Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants