User Tools

Site Tools


newdevs:db:fm

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
newdevs:db:fm [2025/03/28 13:51] – [permacrud xmlns] tmccannanewdevs:db:fm [2025/07/29 11:26] (current) – [reltype] smayo
Line 18: Line 18:
   * [[evergreen-user:reporting_data_dictionary|Reporting data dictionary]]   * [[evergreen-user:reporting_data_dictionary|Reporting data dictionary]]
  
 +While it was written for the old desktop client, [[xul:birds_eye_view|this page is a good starting place to learn about the Fieldmapper and API calls]]:
  
-===== Things to Add to This Page===== +{{METATOC >:xul:birds_eye_view}}
-  * Information about the main fieldmapper classes +
-  * Example of how to navigate the fieldmapper +
-  * Relationship of the fieldmapper to reports  +
-  * Relationship of the fieldmapper to the PostgreSQL database schemas+
  
  
Line 94: Line 91:
  
 === reltype === === 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 === === key ===
Line 137: Line 147:
 == owning_user == == owning_user ==
  
 +
 +===== Things to Add to This Page: =====
 +  * Information about the main fieldmapper classes
 +  * Example of how to navigate the fieldmapper
 +  * Relationship of the fieldmapper to reports 
 +  * Relationship of the fieldmapper to the PostgreSQL database schemas
newdevs/db/fm.1743184309.txt.gz · Last modified: 2025/03/28 13:51 by tmccanna

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki

© 2008-2022 GPLS and others. Evergreen is open source software, freely licensed under GNU GPLv2 or later.
The Evergreen Project is a U.S. 501(c)3 non-profit organization.