Fork me on GitHub
#datomic
<
2018-07-19
>
henrik11:07:59

Is it a good idea to create something like :internet/email, and inject it everywhere for people, companies, what have you, rather than :person/email, :company/email and so on?

chrisblom11:07:36

i prefer specific attributes over generic attributes

chrisblom12:07:54

different entities may have different requirements, and it makes it easier to do queries like “give me all the email adresses of users”

chrisblom12:07:26

for example, for users you may want to use email’s as id’s, but for companies not

chrisblom12:07:42

or: a user can have only one email, but a company can have more

chrisblom12:07:40

another issue is that an email address might be used as the :internet/email of both a company and a user. If want you use the this email as an id, you will run into trouble

henrik12:07:29

Right, I see your point.

chrisblom12:07:10

there are valid use cases for generic attributes of course

henrik12:07:40

I’ve got to think through where to draw the line. Theoretically, you could say that names are unique as well. This person-entity refers to the name-fact “Jane Smith.” As does a bunch of other person-entities. The utility would be minimal though.

dominicm12:07:14

https://docs.datomic.com/cloud/whatis/data-model.html#sec-5 > For example, an application that wants to model a person as an entity does not have to decide up front whether the person is an employee or a customer. It can associate a combination of attributes describing customers and attributes describing employees with the same entity. An application can determine whether an entity represents a particular abstraction, customer or employee, simply by looking for the presence of the appropriate attributes. I feel like Datomic is encouraging :internet/email here.

👍 8
henrik12:07:22

I figure URLs and emails should be candidates for uniqueness. You could then theoretically pull out every entity where that URL or email appears.

chrisblom12:07:28

what if a company and user share the same email?

henrik12:07:19

They’ll point to the same datom I suppose. That’s kind of what I contemplate might be a feature.

chrisblom12:07:11

i can be if that is what you want

chrisblom12:07:15

i’d say they point to the same entity, not datom

👍 4
chrisblom12:07:51

a datom is a single [entity attribute value …] fact

henrik12:07:18

This is what I’m trying to wrap my head around at the moment. In words, I’d like to express it as “There is such a thing as an email that is <mailto:[email protected]|[email protected]>.” And as a separate fact, “Person X has declared that their email is [email of <mailto:[email protected]|[email protected]>]”

👍 4
henrik12:07:06

Although, perhaps this is chopping up the conceptual world too finely.

chrisblom12:07:31

It is an option

chrisblom12:07:36

{:db/id 123
 :internet/email ""}

{:db/id 456
 :person/id "X"
 :person/email 123}

chrisblom12:07:00

Then later you could add:

chrisblom12:07:28

{:db/id 789
 :company/id "Acme Corp."
 :company/email 123}

henrik12:07:31

In the domain I’m looking at, email adresses may show up on people, organisations, book reviews, journal articles, etc. etc., and this may be a way to tie them together, given that both URLs and emails have UUID-like properties. If the same email appears on two of these entities, there’s likely a relation, barring typing errors.

chrisblom12:07:01

yes that seems reasonable to me

henrik12:07:28

But then I have to face the fact that there may eventually be overhead as well. Such as “<mailto:[email protected]|[email protected]>”, which was then corrected to “<mailto:[email protected]|[email protected]>”. Now there’s a lonely email, unconnected to anything, floating around.

henrik12:07:47

Now I’ve got to write a vacuum cleaner which goes around and retracts pointless emails.

henrik12:07:19

Or a thing that checks if this was the last reference to the email. If so, retract it.

henrik12:07:04

It’s sounding a lot like garbage collection at the moment.

chrisblom12:07:29

yes, but it seems doable

chrisblom12:07:42

you could use transaction function to rename emails, that retracts email entities once they are no longer used

stuarthalloway12:07:04

@henrik I don't think I would bother removing such things without a tested performance requirement showing that it matters.

henrik12:07:29

Right. So, let ’em float.

stuarthalloway12:07:01

And you always have enough info to change your mind later, because Datomic.

😊 8
henrik12:07:36

True. I’ll give it a shot and see what happens. Thanks to both of you.

stuarthalloway12:07:27

I am lazier than @U9CQNBXDX 🙂 -- if I did have such a batch cleanup job I would write it as a 5-line script, not a tx fn.

chrisblom12:07:30

i forgot to mention that it would be a 4-line tx fn

😂 8
henrik14:07:13

Still not as lazy as doing nothing at all, so that wins 😄

👍 4
chrisblom12:07:40

i think its better to model separate domain types as separate entities: a person can have some relation to a company, but a person is not a company

👍 4
eoliphant14:07:41

yeah, @henrik @chrisblom I’ve been back and forth this as well. For me at least part of the problem has been falling into being ‘unnecessarily relational’ when modeling. One technique I’ve come across that’s a little less common, but pretty powerful (kind of like Datomic lol) is Object-Role Modeling. It has some formalisms around verbalizing models and what have you. There are some ORM tools that do all this crazy transformation to map it into relational models. But you can do a pretty much 1-to-1 mapping of what you come up with in datomic