Skip to content

Commit abb8360

Browse files
Update multiple repositories doc
1 parent 12d7b76 commit abb8360

File tree

1 file changed

+23
-13
lines changed

1 file changed

+23
-13
lines changed

docs/modules/ROOT/pages/known-issues.adoc

Lines changed: 23 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -32,24 +32,34 @@ The behavior can be configured through xref:configuration.adoc#context-close-shu
3232

3333
== Multiple Repositories with related entities [[multi-repos-with-related-entities]]
3434

35-
Users of SQL-Databases usually have a different understanding regarding relations between entities.
36-
They are handled and checked by the database.
35+
In SQL databases, relationships between entities are explicitly defined and enforced by the database system.
36+
This ensures that constraints, such as foreign keys, are consistently maintained.
3737

38-
In the Java object graph we only have the relations defined by the user.
39-
This means that if a contained object has no variable that points to the containing object, it does not know anything about it, and we can only find this relation by searching through the whole object graph.
40-
41-
An example: If an order instance contains several references to articles, there is almost no way to find the containing order of an article.
42-
Of course, we could search the whole object tree and then finally find the parent, but that would not be effective at all.
38+
In contrast, relationships in a Java object graph are solely defined by the developer.
39+
If an object within the graph does not maintain a reference back to its parent or containing object, it has no inherent knowledge of that relationship.
40+
Consequently, finding such a relationship requires searching the entire object graph, which can be highly inefficient.
4341

4442
image::DependingClasses.svg[Example structure with orders and articles]
4543

46-
Now what if we deleted a referenced article from the article repository?
44+
Example Scenario:
45+
Consider an *order object* that contains references to several *article objects*.
46+
In this case, determining which order contains a specific article is nearly impossible without traversing the entire object graph to locate it.
47+
This lack of direct reference contrasts sharply with the behavior of SQL databases.
48+
49+
What Happens When an Article is Deleted?
4750

48-
-> in a sql database we would expect an exception to arise, because we shouldn't remove a referenced article.
51+
1. In an *SQL Database*: +
52+
Attempting to delete an article that is still referenced (e.g., by an order) would typically result in an exception. +
53+
The database enforces referential integrity, preventing the deletion of a referenced entity.
4954

50-
-> but in Spring-Data-Eclipse-Store we can easily remove this article, because the system doesn't know about any references to it.
51-
This results in the article getting removed, but the article actually still exists in the order.
52-
Furthermore, if we store the order again, the article will be existing in the article repository once more.
55+
2. In *{product-name}*: +
56+
Deleting an article from the article repository is allowed, even if it is still referenced elsewhere. +
57+
The system does not track or enforce such references.
58+
As a result:
5359

54-
This is simply a very different behaviour from SQL databases and must be acknowledged.
60+
* The article is removed from the repository.
61+
* However, the order still retains its reference to the now-deleted article.
62+
* If the order is subsequently saved, the article is reintroduced into the repository.
5563

64+
This behavior is fundamentally different from the strict relationship management seen in SQL databases.
65+
Developers must be aware of these differences to avoid unintended side effects in their applications.

0 commit comments

Comments
 (0)