> How can I import `tsv` and/or n-triplets file into v2 XTDB so I can run a couple of queries on WatDiv ? I can't offer easy instructions for that right now as

> How can I import `tsv` and/or n-triplets file into v2 XTDB so I can run a couple of queries on WatDiv ? I can't offer easy instructions for that right now as we've not adapted the benchmark for the 2.x branch yet (and I would not expect performance to match 1.x right now anyway), although all the code one might need is in the repo for 1.x already and should be straightforward enough to convert to the new APIs given some familiarity with Clojure: https://github.com/xtdb/xtdb/blob/master/bench/src/xtdb/bench/watdiv_xtdb.clj https://github.com/xtdb/xtdb/blob/master/bench/src/xtdb/benc... > Was it Datomic that played a pioneering role in this shift ? I know Datomic has inspired a lot of people - certainly our entire team - but I'm not sure how much it's influenced the existence of things like Cozo or the wider database ecosystem. I get the feeling that Datomic's impact on application developer communities and library builders has been far greater (also amplified further by DataScript) than the impact on established database vendors & research communities. It has at least been good to see more systems start treating data immutably and exposing time-travel capabilities, even if Datomic was merely ahead of the curve rather than a direct inspiration. > They are forcing users to create queries and data models through the cumbersome process of breaking down and building n-ary relations from triplets. I believe that the remedy lies in developing robust transformation functions capable of handling input and output across triplets, tabular, or nested data structures. Despite originally being attracted to triple-oriented modeling I have come around to agreeing with this point of view. Processing with n-ary relations is unavoidable so the idea of not persisting them also feels inherently limiting. I am also quite drawn to "Object Role Modeling" (though I've not yet applied it in anger) which really demands n-ary tuples, and the RelationalAI folks seem to have reached a similar conclusion: https://docs.relational.ai/rel/concepts/relational-knowledge-graphs/schema-visualization#schema-visualization-orm-and-lpg-diagrams https://docs.relational.ai/rel/concepts/relational-knowledge... > in my opinion, the ideal solution to the DBMS-database challenge resides at the application level and within the realm of database modeling I generally agree with this too. All I know for certain is that almost everything in software should be more relational and declarative, and then machine learning stands the best chance of figuring out how to make things fast. Good discussion :)