Fork me on GitHub
#datomic
<
2020-07-23
>
nlessa12:07:53

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

David Pham12:07:31

I hope it becomes open source xD

❤️ 6
stuarthalloway12:07:52

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.

👍 3
👏 3
David Pham12:07:49

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

nlessa13:07:47

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.

tvaughan13:07:24

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

👍 3
💯 3
nlessa13:07:46

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

🙏 6
stuarthalloway13:07:19

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.

stuarthalloway13:07:05

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.

👍 45
calebp14:07:34

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

drewverlee15:07:11

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.

drewverlee15:07:21

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?

favila16:07:00

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

favila16:07:28

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

calebp16:07:19

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.

favila16:07:28

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

favila17:07:23

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?

calebp17:07:14

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.

calebp13:07:36

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.

drewverlee20:07:18

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.

favila20:07:26

datomic.api/q does not take a map

favila20:07:40

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

favila20:07:14

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

favila20:07:45

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

drewverlee20:07:24

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

drewverlee20:07:14

query & inputs

drewverlee20:07:29

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)