Patterns for defining non-persistent entity relationships to traverse via business logic?

48 views Asked by At

Background

I'm using Spring Data MongoDB to persist domain objects into their own respective collections. I want to avoid storing persistent references for various reasons, but primarily because interested processes use "casual" relationships in ways specific to their use case. For example, a Document may have an ObjectID entityInCollectionXyzId; field implicitly related to a document in CollectionXYZ, but the meaning of the relationship is known only to the process that owns it.

The problem

As part of a larger effort, I need to perform administrative operations on specific Documents that cascade to their informally-related descendants. Such operations transfer ownership of the document and its descendants to the acting super user who does not care why the relationships exist, but nevertheless needs to perform subsequent lookups to find and modify descendants. The trouble lies in identifying the informally-related descendants so they can be traversed programmatically.

The question

Is there a well known pattern or term for this concept, in which a relational schema is defined somewhere but is invisible to the database and/or persistence layer?
I'd rather not reinvent the wheel if something like this exists, but at the very least I'd like to know if what I'm describing has a name or resembles some high-level concept.


Additional thoughts and unsuccessful leads

I considered hardcoding many big bespoke methods for each particular use case and hierarchical entry point, but this approach would not be configurable by users, and loosely-coupled validation would likely become a maintenance burden.

The solution I'm imagining could use something like "dumb" ORM-style annotations to identify relationships so they can be traversed programmatically, or perhaps separate subclasses or delegates that would fail compilation or validation if one side changed without the other. Using the former as an example (pardon the goofy signature and wrong hibernate semantics):

@Document
class CollectionABC {
    @Id ObjectId id;

    @ManyToOneButNotHibernate(target = CollectionXYZ.class, field = "id")
    ObjectId entityInCollectionXyzId;
}

@Document
class CollectionXYZ {
    @Id ObjectId id;
    // more nested descendants maybe
}

// exercise left to the reader (me) (or perhaps some magic library!!)
interface SomeGraphBuilderThing {
    ObjectGraph traverse(/* relevant args */);
}

I will happily remove this code block if it's distracting

In either case I would prefer to use an existing solution if possible, or at least have some reference material to use as guidance.

My futile attempts at searching led me to a few seemingly-relevant names such as Meta Model and Surrogate Model but they seem to miss the mark. Any other promising leads suggest migrating to a graph database which is a non-option. I also spent some time perusing the Spring Data internals searching for any high-level APIs that would let me define and handle traversal myself to no avail.

0

There are 0 answers