Fork me on GitHub
Jakub Holý (HolyJak)10:08:54

Hi! Has anyone tried to build Gremlin support for Datomic (for Apache TinkerPop v3; I see there was a PoC "blueprint" for an old version)? Thanks

Jakub Holý (HolyJak)14:08:28

Does Datomic (on-prem) support Full-Text Search or does it have any integration with ElasticSearch? Neither scanning the docs nor searching the Internet answered that. Thank you!


It’s very limited and you cannot remove it later. If you want flexible and powerful fulltext search over large text corpuses I suggest feeding the datomic transaction log into a secondary elasticsearch service and using that for fulltext searches.


If you just have tiny text fields and just want some kind of low-headache fuzzy matching, it’s probably fine.

Jakub Holý (HolyJak)08:08:11

@U09R86PA4 perhaps it would be good if listed :db/fulltext in the "You can never alter ..." list? Not sure how to propagate that suggestions to the Datomic team...


Hi @U0522TWDA it's already there: You can never alter _:db/valueType_, _:db/fulltext_, _:db/tupleAttrs_, _:db/tupleTypes_, or _:db/tupleType_.

Jakub Holý (HolyJak)11:08:41

Ah, thank you, I'm blind today :)


Do the following two dbs exhibit the same performance?

(def db (d/db conn))
(def db-as-of (d/as-of db (:t db)))
Put another way, as (:t db) grows further from the current :t (e.g., current :t is 1 > (:t db), 10 >, ..., 1e6 >, ...), does db pay the same performance penalty an as-of db pays? (current :t = (:t (d/db conn))).


A “current” (unfiltered) db is always fastest, because it only ever has to retrieve the current index. It only merges against that index and the memlog.


Potentially an as-of >= last-indexed-t will do the same and be the same complexity, but I donno.


anything older is going to have to look at the history or mid-history indexes to reconstruct the value at that moment in time.


whether this is slower-enough in practice depends on object cache, valcache, datasize, selectivity of queries, etc


but you’re merging across 3-4 indexes instead of just 2


Interesting, thanks for responding. By "anything older is going to ...", do you mean both an as-of and an unfiltered db would go down this path?


an unfiltered db is by definition a “now” db, so only looks at the “now” index--the one that only has assertions valid at the moment it was indexed.


By “anything older” I mean anything that needs to look at datoms older than the last-indexed T