I, for one, am not going back to SQL if I can avoid it.. I think datalog is so much better suited for Clojure apps

Hey @U03DKTAF52P - thanks for the feedback! Given unlimited resources we'd love to offer a full Datalog API early in the process also, but realistically we simply have to focus on shipping SQL at the moment (and there's still plenty of work still to be done). HoneySQL would probably be my go-to recommendation for using Core2 via Clojure for the foreseeable future

> datalog is so much better suited for Clojure apps This is the benchmark for us to make SQL more pleasant to work with 🙂

how does core2 have “tables”? like the you can just INSERT INTO people without defining people?

SQL isn’t S-expression language, so idk how it could feel as natural as a simple clojure data structure, but I eagerly await what you come up with 😄

tables are more like "collections" (in Mongo parlence), i.e. just dynamic ad-hoc groupings of entities (although we're not really using the word "entities" in Core2)

so the “any entity can have any attribute” of datalog doesn’t really apply in core2… they are separated by type

yes, but you could always just use one giant table 🙂

@U11SJ6Q0K have you used HoneySQL before much? Does it fall short for satisfying your desire for S-expressions?

like in datalog I could find users, organizations, products with a [:find ?e :where [?e :name "foo"]

anything with a name, but if they were different “tables” then I guess that wouldn’t work

but would if you use a giant table

in that case, yep agreed, but using non-namespaced keywords (not domain aligned) isn't very usual though... or is it for you?

not very, but in some cases different “types” of entities do share keys

many domains have some common fields that are present in multiple “tables”

I guess in SQL you can use table inheritance for those

I think at worst you can always use tools like UNION + subqueries to workaround these sorts of problems if they come up

re: honeysql, I’ve dabbled with it but not that much… maybe it works ok

but I really want nested structures, not rectangle shaped results… so doing pull with nested entities in queries is very common

back in the day I made specql https://tatut.github.io/specql/ to try and get the common SQL boilerplate writing out

main problem I have is the constant annoying mapping between deeply nested hierarchical data to table rectangles

> I really want nested structures, not rectangle shaped results this is already a massive focus area for Core2 so I'm very confident we'll have something rather compelling to offer here. It can already round-trip arbitrary nested structs/objects & arrays, which is the foundations for doing more complex projection

if you can solve the writing side as well without needing shredding, that would be good

^ yes this too, like the indexes themselves will (eventually) be dynamically generated based on actual query workloads, including any nested data. Håkan's talk next week will cover some of the ideas here https://www.juxt.pro/strange-loop (the recording should be available on the SL youtube channel soon after, hopefully!)