haskey-btree
B+-tree implementation in Haskell (by haskell-haskey)
pool-conduit
Persistence interface for Haskell allowing multiple storage methods. (by yesodweb)
| haskey-btree | pool-conduit | |
|---|---|---|
| - | 9 | |
| 27 | 476 | |
| - | 0.4% | |
| 0.0 | 6.7 | |
| about 6 years ago | 7 days ago | |
| Haskell | Haskell | |
| BSD 3-clause "New" or "Revised" License | MIT License |
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
haskey-btree
Posts with mentions or reviews of haskey-btree.
We have used some of these posts to build our list of alternatives
and similar projects.
We haven't tracked posts mentioning haskey-btree yet.
Tracking mentions began in Dec 2020.
pool-conduit
Posts with mentions or reviews of pool-conduit.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2022-05-06.
-
Problem with Persistent.runSqlPool and Servant Handel
I understand that the "new" version of Persistent requires Servant Handler to be MonadUnliftIO which is not the case. I also understand that I am suppose to use acquireSqlConn somehowe (following this this), but I can't figure it out. Any ideas ?
-
Was simplified subsumption worth it for industry Haskell programmers?
I don't think there's any malicious intent. It seems pretty clear that the motivation here is to simplify the type checker considerably, which is a really good reason to do something. Heck, I've got an open issue for deleting a feature in persistent which (according to the lack of comments on the issue) only ever used by persistent's own test suite.
-
[ANNOUNCE] GHC 9.2.2 is now available!
PR submitted: https://github.com/yesodweb/persistent/pull/1366 :)
- Simple Servant + Persistent + Katip template for starting a new project
-
Async Control Flow
Ha, I spotted a possible resource leak here. If stmtFinalize fail, then the connection won't be closed.
-
Using a different version of a package than what exists in resolver.
text Cloning b1e32adfe1da49cd9df997a13bd0c5b391486f5c from https://github.com/yesodweb/persistent.git No cabal file found for Repo from https://github.com/yesodweb/persistent.git, commit b1e32adfe1da49cd9df997a13bd0c5b391486f5c
What are some alternatives?
When comparing haskey-btree and pool-conduit you can also consider the following projects:
rocksdb-haskell - Haskell bindings to RocksDB (http://rocksdb.org)
lmdb - Lightning MDB bindings for Haskell
sqlite-simple - Mid-level bindings for sqlite
HongoDB - A Simple Key Value Store
direct-sqlite
hocilib - A lightweight Haskell binding to the OCILIB C API