datomic

Ask questions on the official Q&A site at https://ask.datomic.com!
nlessa 2020-07-23T12:52:53.387200Z

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

2020-07-23T12:56:31.387400Z

I hope it becomes open source xD

2❤️
stuarthalloway 2020-07-23T12:56:52.387800Z

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.

1👍1👏
2020-07-23T12:57:49.388700Z

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

nlessa 2020-07-23T13:05:47.394900Z

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.

tvaughan 2020-07-23T13:24:24.395Z

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

1👍1💯
nlessa 2020-07-23T13:32:46.395200Z

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

2🙏
stuarthalloway 2020-07-23T13:55:19.395700Z

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.

stuarthalloway 2020-07-23T13:56:05.395900Z

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.

15👍
2020-07-23T14:10:34.397100Z

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

2020-07-23T15:34:11.401800Z

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.

2020-07-23T15:43:21.403200Z

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?

2020-07-23T16:12:19.403700Z

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.

2020-07-24T13:27:36.410800Z

I guess there’s nothing stopping me from creating my own attribute to mark the relationship as “isComponent” when modeled in the other direction. The convenience features of retractEntity and (pull [*]) wouldn’t work, but the data would still be there.

favila 2020-07-23T16:48:02.404Z

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

favila 2020-07-23T16:49:00.404300Z

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

favila 2020-07-23T16:49:28.404500Z

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

favila 2020-07-23T16:52:28.404800Z

> 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”?

2020-07-23T16:56:24.405Z

Yes.

favila 2020-07-23T17:31:23.405200Z

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?

2020-07-23T17:38:14.405400Z

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.

2020-07-23T17:48:27.405600Z

as always ty @favila

2020-07-23T20:14:18.408500Z

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
 
do the datomic functions have specs? I'm worried this/my project might be shadowing things in a way i dont see yet.

favila 2020-07-23T20:20:26.408800Z

datomic.api/q does not take a map

favila 2020-07-23T20:20:40.409Z

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

favila 2020-07-23T20:21:14.409200Z

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

favila 2020-07-23T20:21:45.409400Z

(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)

2020-07-23T20:23:24.409600Z

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

2020-07-23T20:24:03.409800Z

oh

2020-07-23T20:24:14.410Z

query & inputs

2020-07-23T20:25:29.410200Z

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)