This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-07-19
Channels
- # aleph (3)
- # beginners (90)
- # boot (1)
- # cider (1)
- # cljdoc (23)
- # clojars (1)
- # clojure (91)
- # clojure-dev (8)
- # clojure-greece (1)
- # clojure-italy (17)
- # clojure-japan (1)
- # clojure-nl (6)
- # clojure-spec (4)
- # clojure-uk (89)
- # clojurescript (48)
- # core-async (5)
- # cursive (79)
- # datascript (1)
- # datomic (40)
- # duct (1)
- # emacs (7)
- # figwheel-main (2)
- # graphql (7)
- # jobs (5)
- # nyc (5)
- # off-topic (61)
- # other-languages (2)
- # parinfer (6)
- # re-frame (63)
- # reagent (131)
- # ring-swagger (6)
- # shadow-cljs (158)
- # spacemacs (14)
- # tools-deps (15)
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?
different entities may have different requirements, and it makes it easier to do queries like “give me all the email adresses of users”
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
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.
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.
I figure URLs and emails should be candidates for uniqueness. You could then theoretically pull out every entity where that URL or email appears.
They’ll point to the same datom I suppose. That’s kind of what I contemplate might be a feature.
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]>]”
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.
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.
Now I’ve got to write a vacuum cleaner which goes around and retracts pointless emails.
Or a thing that checks if this was the last reference to the email. If so, retract it.
you could use transaction function to rename emails, that retracts email entities once they are no longer used
@henrik I don't think I would bother removing such things without a tested performance requirement showing that it matters.
And you always have enough info to change your mind later, because Datomic.
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.
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
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