Apologies if this isn’t coherent. I’m still getting used to graph-db land. For the sake of argument, let’s say I’m storing dyadic relationships from an external data source. Narrowed, my type is,
type User {
subscribes_to: [User]
}
Requests to the external source are not only expensive in terms of latency, but rate-limited. Thus, I’m using a refreshed_at facet on the subscribes_to edge. To add the relationship, I’m doing an upsert that finds the ego and alter. The caveat is that there is a special class of subscriptions for which the stale subscription value takes a sentinel value (a very far off date) that essentially means DO NOT OVERWRITE. Is there a way to conditionally set the facet value to the one given if the sentinel is not present? Or, I should say, what is the best practice for doing so?
I’m leaning towards adding an explicit boolean sentinel field. My upsert simply won’t write to it (implicitly via json:"*,omitempty"). But in my head, a few bools here and there starts adding up to real storage costs at scale.
Hrm. I tried my “leaning towards” solution and it didn’t work. It seems like facets don’t merge, they overwrite? I guess this is part of the “not first class citizens” warning?
Yes, still have some improvements to be done in facets. You can search in Dgraph’s repo and give a +1 or “up +1” or “thumbs up”. This way we know that this feature is important for the community and we analyze the priorities better.
Continuing
Can you clarify which upsert you are talking about?
If that’s what I’m thinking, it’s not possible for now. Only when multiple mutations within a transaction are possible. For now the PR has not been merged. And when it is, only in the next RC or next official release.
I found a better way to do what I needed that has no overwrite related issues. Even if facets merged implicitly, I prefer my new solution: “explicit is better than implicit,” and all that.