I’ve got a system that makes liberal use of :component. Like, I’ve got a report entity and it has component references to the many observations one may make on a report. Well and fine.
But I have also got report types which are composed of many section types. And the sections should be shareable and re-usable across many different types of reports. But alas, the section-types are components of the report-types. So if I remove a report type, it vanishes not just from that type, but everywhere in the system.
Is it possible to “undo” the :component designation, or am I stuck? I think in the past, similar mistakes were handled by creating a whole new entity with the correct/desired changes. But that has left me with all kinds of “red herrings” in the DB as I have to guess which of the similarly named entities is the actual one in use.
Thanks for the speedy reply Dustin. This will save me some pain.
If I’m understanding the component behavior correctly (and from my reading), if an entity is deleted, so are all of its components. But Datomic doesn’t object to you have any given entity being a component of multiple other entities.
I’m sure what my predecessors wanted was for, e.g., entity Z to be a component A, B and C, but only removed if all of A, B and C are also removed.
per my understanding it doesn’t make sense for an entity to be a component of many parents. component is meant to mean a direct 1:1 parent-child relationship. if a component has multiple parents, i think that is mis-modeled. the retract behavior would be undefined (probably just retract the entity if any one of the parents are retracted but you should check). this is per my understanding, i could be wrong.
This is also my understanding. It just seems like the wrongness might helpfully be checked by the DB. “You can’t make this a component when it’s a component elsewhere.” Perhaps too intrusive, however.
i don’t see why that would be too intrusive but having thought about it, it would add a query inside the transaction which is probably not okay generally
Yup. Or, in my case, not use isComponent and create some kind of check for orphan situations. (Although, in my particular case, the use is just flat out wrong and against the design spec.)