Differences

This shows you the differences between two versions of the page.

--- newdevs:db:fm [2025/07/26 16:55] – Adding link and TOC of xul:birds_eye_view; moving Things to Add to the bottom sleary
+++ newdevs:db:fm [2025/07/29 11:26] (current) – [reltype] smayo
@@ Line 91: / Line 91: @@
 === reltype ===
-These distinctions are to indicate key directionality. They are not to indicate nullability.
-  * has_a
+There are 3 reltypes:
-  * has_many
+  * has_a -- the field physically exists as a column (as in, does not have the @oils_persist:virtual="true" attribute) on the SQL relation being described, and points to a unique key column (usually the primary key) of another SQL relation represented by another IDL class.
-  * might_have
+  * has_many -- the field is does NOT physically exist on the described SQL relation, but instead exists as a class property that will be filled with a LIST of zero or more objects built from rows on another SQL relation, described by the <link>'s @class attribute, which have a field that contains the local SQL relation's (effective) primary key.
+  * might_have -- the field does NOT physically exist on the described SQL relation, and there is exactly one row on another SQL relation described by the <link>'s @class attribute that contains the local SQL relation's primary key.
+In other words, "might_have" is EXACTLY THE SAME as "has_many", but is guaranteed to always hold exactly one object, or NULL, rather than always hold a LIST of zero or more objects.
+Here's how to decide which reltype attribute to use:
+  * If the field is not virtual, but backed by a real column: ALWAYS use "has_a"
+  * If the field is virtual, but there's only ever going to be, at most, one row on the other end of the join: ALWAYS use "might_have"
+  * If the field is virtual, and there can be any number of rows on the other end of the join: ALWAYS use "has_many"
 === key ===