Differences

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

--- newdevs:db:fm [2023/05/22 10:26] – [links] tlittle
+++ newdevs:db:fm [2025/07/29 11:26] (current) – [reltype] smayo
@@ Line 2: / Line 2: @@
 ====== The Fieldmapper ======
-The fieldmapper (fm_IDL.xml) maps the fields! It defines objects’ fields, linked fields from other objects, and permissions needed to access various things. Most of the Evergreen code (including the reports engine) accesses the database content via the fieldmapper rather than accessing the database directly.
+The fieldmapper (''fm_IDL.xml'') maps the fields! It defines objects’ fields, linked fields from other objects, and permissions needed to access various things. Most of the Evergreen code (including the reports engine) accesses the database content via the fieldmapper rather than accessing the database directly.
   * [[https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/examples/fm_IDL.xml;h=a4fb45b078c1f80ccfdcb82d9bc2a8ee40fc749a;hb=HEAD|fm_IDL.xml in Evergreen git repository]]
@@ Line 14: / Line 14: @@
   * <nowiki>https://[your domain].org/reports/fm_IDL.xml</nowiki>
+Outline of fieldmapper classes:
-===== Things to Add to This Page: =====
+  * [[evergreen-user:reporting_data_dictionary|Reporting data dictionary]]
-  * Information about the main fieldmapper classes
-  * Example of how to navigate the fieldmapper
+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]]:
-  * Relationship of the fieldmapper to reports
-  * Relationship of the fieldmapper to the PostgreSQL database schemas
+{{METATOC >:xul:birds_eye_view}}
 ===== Parts of the Fieldmapper =====
-==== Class header ====
+==== class header ====
 === class ===
@@ Line 37: / Line 38: @@
 === oils_obj:fieldmapper ===
+=== oils_persist:cardinality ===
+This is an estimate of how many records are expected in this class.  This is used by the UI in some cases to determine whether or not it's reasonable to pre-fetch all the records of this class.  There are three possible values:
+  * low (less than 100 records)
+  * high (100-1000 records)
+  * unbounded (more than 1000 records)
 === oils_persist:tablename ===
@@ Line 42: / Line 51: @@
 === oils_persist:virtual ===
+This essentially means that the class or field is not "real" in the actual database table, only in the context of the IDL. It is often used for links to other classes:
+<code><field reporter:label="Hours of Operation" name="hours_of_operation"
+ oils_persist:virtual="true" reporter:datatype="link"/></code>
+It can also be used to indicate such things as a view that is defined by SQL in the IDL rather than in the database.
 === oils_persist:readonly ===
@@ Line 51: / Line 65: @@
 === reporter:label ===
 This will be the name of your view in list of available report sources in the reporter, so it should be in readable language.
 ==== fields ====
@@ Line 62: / Line 77: @@
 === reporter:datatype ===
+  * bool - true/false
+  * text
+  * int - a whole number
+  * float - a decimal number
+  * link - a reference to a different class.
+  * id - a whole number. This class's links are other class's ids.
+  * money - an amount of money
+  * org_unit - a library/sublibrary etc.
+  * interval - an amount of time shown as a number followed by a letter for the unit e.g. 20h for 20 hours or 7d for seven days
+  * timestamp - an unchanging point in time
 ==== links ====
 === link field ===
 === 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 ===
@@ Line 86: / Line 123: @@
 === permacrud xmlns ===
 <code><permacrud xmlns="http://open-ils.org/spec/opensrf/IDL/permacrud/v1"></code>
-This should be the opening tag for your peramcrud area.
+This should be the opening tag for your permacrud area.
 === actions ===
@@ Line 97: / Line 134: @@
 If using the create/update/delete actions, the class must also be mapped to an **[[newdevs:db:fm#oils_persist:tablename|oils_persist:tablename]].**
+If you specify a permission, you must also include a ''global_required'' or ''context_field'' attribute or a ''context'' element.  Otherwise, you will get the error message "Invalid object or insufficient permissions".
 == context_field ==
@@ Line 108: / Line 147: @@
 == 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