@mihaelkonjevic nice work https://github.com/retro/konserve-pg π
what kind of benefits does postgres provide for you?
I can't speak for Mihael, but at $work Postgres is the only database that we are allowed to deploy, so I can see how having a backend for Postgres might be useful (albeit not optimal)
that makes sense. it should not be too bad, i hope
after all people also use postgres as a JSON blob store nowadays
@whilo for me it's ability to deploy to Heroku. I want to be able to quickly prototype backends for the apps I'm working on because backend mocking is not really a feasible strategy for anything except the simplest cases. So in our case I would prototype an app in a few weeks (both on frontend and backend) which would allow me to nail the GraphQL schema early in the process. After that the backend team takes over and implements the real backend based on the prototype. So for my usecase, cheap (free) way to quickly deploy a datomic-like backend is extremely valuable
that sounds like a super reasonable workflow
you are missing the flexible postgres protocol dispatch for that, right?
Yeah, but I'm ok with patching datahike in my codebase if you're in the middle of re-architecting. It depends on how valuable is pg driver for the rest of the community
i did a proof of concept of extensible stores w/ multimethods in my fork https://github.com/purrgrammer/datahike/pull/1/files not sure if that's what you folks had in mind
@bandarra yeah, thatβs it. I would only add :default
implementations that throw exceptions if the method is not defined
I also took a stab at the rolling hash for the DB that @whilo suggested, there is an explanation of a couple possible approaches in https://github.com/purrgrammer/datahike/pull/3
for me it makes sense that the hash of DB incorporates hashes of atoms added and then retracted, is part of the history of the DB. supporting consistent hashing of DB
and FilteredDB
forces us to recompute hashes when retracting datoms too..
not sure how valuable is supporting hashing of FilteredDB
another option would be to support hashing in hitchiker-tree as suggested in https://github.com/replikativ/datahike/issues/38#issuecomment-489301927 going to take a π
I think the hitchhiker tree option is not as good, because it means databases with the same values, but different indices are not the same. If we can track the hashing in datahike along your PR then this would be optimal, I think.
π i'll tidy it up based on feedback and open a PR to datahike
if possible to the index-protocols branch
weβll release a beta version using that next week
sure
π thanks
let me know your thoughts on the PR, thanks for your time! https://github.com/replikativ/datahike/pull/51
alright, Iβll review it tomorrow.
These sound like really great rationales to me. Thanks @mihaelkonjevic!