You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/modules/ROOT/pages/known-issues.adoc
+23-13Lines changed: 23 additions & 13 deletions
Original file line number
Diff line number
Diff line change
@@ -32,24 +32,34 @@ The behavior can be configured through xref:configuration.adoc#context-close-shu
32
32
33
33
== Multiple Repositories with related entities [[multi-repos-with-related-entities]]
34
34
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.
37
37
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.
43
41
44
42
image::DependingClasses.svg[Example structure with orders and articles]
45
43
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?
47
50
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.
49
54
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:
53
59
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.
55
63
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