Clojurians Log v2

Hi, any thoughts about future of Datomic as a product after acquisition of Cognitec by Nubank?

I hope it becomes open source xD

We expect the future for Datomic to be "like today, but more so." Datomic development, product offerings, and customer relationships will continue and grow, as they have.

Do you think companies might see some conflict of interest on Datomic? Especially financial companies?

well, I foresse some fintechs in Brazil second guessing their use of Datomic… In the end what matters is how Nubank will treat Datomic as a product by itself or their “inner most important technology”…For me that lived the story of Apple acquisition of Next(and WebObjects), and the long demise of WebObjects as product and more and more as the “most important technology of Apple back-end”) it’s a bit frightening.

That was a looong time ago. The thinking that some critical piece of infrastructure is best kept proprietary as some sort of competitive advantage has changed considerably. Adapting to new technologies and swapping one for another when the new thing offers cost savings or improves customer experience, for example, and, perhaps most importantly, pushing off job training costs to the broader open source community are the new normal in this regard, I think

I think like you and hope that Nubank/Cognitec act like that. Lets see.

Nubank doesn't see any benefits in restricting access to awesome technology. We exist as part of a broader ecosystem, not in isolation, and we all benefit from broader adoption and more scale for both Clojure and Datomic. Nubank doesn't have any incentives or interests in this sense that would conflict with other companies leveraging the same technologies, regardless of industry.

Nubank believes that our experience with Datomic at scale can help optimize and enhance the product and we would love to see all Datomic users benefiting from that progress.

I’m very grateful for “like today, but more so.” Thanks Datomic team

in the datoms call https://docs.datomic.com/client-api/datomic.client.api.html#var-datoms given the :avet index what is the big O time? is it proportional to the number of datoms with the given attribute? Put another way, should i pass an attribute that is rarer? person.name = "drew" Or something where the attribute = value combination is more strict? person.id = id I'm fairly sure the former is more correct but i can't articulate why.

From these docs: https://docs.datomic.com/on-prem/indexes.html#avet I guess if the attribute has an index (which it must) and the value column has an inner sort within in attribute. Then assuming its an efficent tree search it's going to be constant to look up the attribute=value right?

We seem to have a schema modeling conflict between using isComponent and using tuple attributes to create unique values on the component entities. Before tuples were released, we usually defined the relationship from the owning entity to the owned entities and marked the ref attribute as isComponent=true. But if we want to create unique tuple attributes on the owned entities that include the owned entity, we need to define the relationship from the owned to the owner and lose the isComponent. Should it just be a matter of deciding whether isComponent or uniqueness is more important in the relationship? We could model the relationship both ways, but then we have to manage making sure they’re both written.

Correct. This may help understand why: https://tonsky.me/blog/unofficial-guide-to-datomic-internals/

Pretty much any three “start” segments will have an efficient--if not direct node lookup, an array-bisection over a selective segment of the index

so you can always rely on getting the first item from datoms in effectively constant time

> But if we want to create unique tuple attributes on the owned entities that include the owned entity Do you mean “unique tuple attributes on the owned entities that include the owner entity”?

Yes.

What features of isComponent are you sad to lose? The direction of the reference? That backrefs in pulls and entity-map walking are scalar values?

Some of it is the documentation aspect that the owned entities shouldn’t exist without the owners. Whether that’s enforced through retractEntity or other custom code, it’s a piece of data that is lost. Not a huge deal.

as always ty @favila

datomic.api/q takes a map {:query .. :args ... } Where query can be {:find ...} right? I'm getting a spec error that no find clause is specified.

1. Caused by java.lang.IllegalArgumentException
   No :find clause specified

                 query.clj:  310  datomic.query/validate-query
 

datomic.api/q does not take a map

you are thinking of either datomic.client.api/q or datomic.api/query

that said, (datomic.api/q {:find …} arg1 arg2) works

(i.e. anywhere the vector form of a query is accepted, a map form is ok too--the vector is just sugar for the map)

I'm looking at these docs: https://docs.datomic.com/on-prem/clojure/index.html#datomic.api/q > query can be a map, list or string

oh

query & inputs

so qseq (which is my final goal) does take a map. i just sort of skipped reading between the lines it seems.

Usage: (qseq query-map)