I made a basic stab at an AWS DynamoDB backend for datahike: https://github.com/replikativ/datahike/pull/86 (and https://github.com/csm/konserve-ddb)
this is much more modest than the DDB+S3 combo I was also hacking on. I’ll probably keep experimenting there, but was able to put this together quickly.
I'm not sure about the preconditions/constraints, could you provide a link please? Regarding tuples there are planned for 0.3.0 https://github.com/replikativ/datahike#030
nice, konserve
is pretty cool 💯
We have a much stronger precondition system in the pipeline, its target is https://datopia.io/
@bandarra - Attribute predicates: https://docs.datomic.com/on-prem/schema.html#attribute-predicates - Entity specs: https://docs.datomic.com/on-prem/schema.html#entity-specs
1♥️looking forward to tuples! 😄
@whilo cool, I’ll check it out!
the condition system itself is not yet documented there
oh, having control in the sense of being able to opt-out. we also have a dynamo-db backend in the pipeline, although datomic is much more mature of course
it is not just about each individual user having freedom to opt out, it is about adapting the stack to your needs for any user and you profit from that. normal database stacks (even if open source) do not provide this freedom because they have many assumptions hardwired in and very complex. datomic is decomplected, yet proprietary, which is an odd choice in my opinion. i understand that they want to make money though
konserve's list-keys function also does that, at least for our own filestore implementation. the problem is that the indices are stored in the hitchhiker-tree and the query engine benefits from scanning the datoms directly. so keys and values are not split at the moment. if you need to store large values, you can point to an external medium as well though, that will make joining with them slower though.
this is super nice
@csm301 that is super cool. a good excuse to play with dynamodb
@whilo In the jar of hasch (dependency of datahike) there is the folder: /private/js/out
which contains duplicates of clojure, cljs, incognito and hasch namespaces. This results in a ton of warnings when compiling with shadow-cljs and (in my case) results in errors later on.
Looks like this:
log
[2019-11-08 15:11:49.949 - INFO] filename violation for ns incognito.base, got: private/js/out/incognito/base.cljc expected: incognito/base.cljs (or .cljc)
[2019-11-08 15:11:49.950 - INFO] filename violation for ns clojure.string, got: private/js/out/clojure/string.cljs expected: clojure/string.cljs (or .cljc)
[2019-11-08 15:11:49.955 - WARNING] provide conflict for #{hasch.platform} provided by private/js/out/hasch/platform.js and {"/hasch/platform.cljs" #{hasch.platform}}
[2019-11-08 15:11:49.956 - INFO] filename violation for ns cljs.reader, got: private/js/out/cljs/reader.cljs expected: cljs/reader.cljs (or .cljc)
[2019-11-08 15:11:49.957 - INFO] filename violation for ns cljs.test, got: private/js/out/cljs/test.cljs expected: cljs/test.cljs (or .cljc)
[2019-11-08 15:11:49.957 - INFO] filename violation for ns cljs.pprint, got: private/js/out/cljs/pprint.cljs expected: cljs/pprint.cljs (or .cljc)
[2019-11-08 15:11:49.957 - WARNING] provide conflict for #{hasch.core} provided by private/js/out/hasch/core.js and {"/hasch/core.cljc" #{hasch.core}}
[2019-11-08 15:11:49.958 - WARNING] provide conflict for #{hasch.benc} provided by private/js/out/hasch/benc.js and {"/hasch/benc.cljc" #{hasch.benc}}
[2019-11-08 15:11:49.962 - WARNING] provide conflict for #{incognito.base} provided by incognito/base.cljc and {"/private/js/out/incognito/base.js" #{incognito.base}}
[2019-11-08 15:11:50.273 - WARNING] provide conflict for #{cljs.reader} provided by cljs/reader.cljs and {"/private/js/out/cljs/reader.js" #{cljs.reader}}
[2019-11-08 15:11:50.273 - WARNING] provide conflict for #{cljs.pprint} provided by cljs/pprint.cljs and {"/private/js/out/cljs/pprint.js" #{cljs.pprint}}
[2019-11-08 15:11:50.274 - WARNING] provide conflict for #{cljs.pprint} provided by cljs/pprint.cljc and {"/private/js/out/cljs/pprint.js" #{cljs.pprint}}
[2019-11-08 15:11:50.275 - WARNING] provide conflict for #{cljs.test} provided by cljs/test.cljs and {"/private/js/out/cljs/test.js" #{cljs.test}}
[2019-11-08 15:11:50.276 - WARNING] provide conflict for #{clojure.string} provided by clojure/string.cljs and {"/private/js/out/clojure/string.js" #{clojure.string}}
[2019-11-08 15:11:50.277 - WARNING] provide conflict for #{cljs.test} provided by cljs/test.cljc and {"/private/js/out/cljs/test.js" #{cljs.test}}
and later:
HeadlessChrome 78.0.3904 (Mac OS X 10.15.1) ERROR
TypeError: cljs.test.report is not a function
at ci.js:177298:11
at Object.cljs$test$run_block [as run_block] (ci.js:148721:19)
at Function.cljs$core$IFn$_invoke$arity$2 (ci.js:177336:18)
at shadow$test$run_tests (ci.js:177318:30)
at Function.cljs$core$IFn$_invoke$arity$2 (ci.js:177377:30)
at shadow$test$run_all_tests (ci.js:177359:34)
at Function.cljs$core$IFn$_invoke$arity$1 (ci.js:177373:34)
at shadow$test$run_all_tests (ci.js:177355:34)
at shadow$test$karma$start (ci.js:183088:34)
at shadow$test$karma$init (ci.js:183094:32)
HeadlessChrome 78.0.3904 (Mac OS X 10.15.1): Executed 1 of 1 ERROR (0.027 secs / 0.004 secs)
https://lambdaforge.io/2019/11/08/clj-kondo-datalog-support.html
31🙂EPIC!
Dynamodb by itself (without Datomic or Datahike on top) is a nightmare for 98% of use cases. So this may be the only good excuse.
Sorry for that, thanks for reporting. Can you open an issue for hasch?