Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
2000_concepts:0200_basics:0400_reference_attributes [2026/08/13 00:50] – ↷ Page moved from docs:2000_concepts:0200_basics:0400_reference_attributes to 2000_concepts:0200_basics:0400_reference_attributes localdev2000_concepts:0200_basics:0400_reference_attributes [2026/08/13 03:43] (current) – external edit 127.0.0.1
Line 23: Line 23:
 Note that the ''MyTransactions'' attribute on the ''Account'' business object represents a “multiple” relationship (account may have multiple transactions) whereas the matching ''MyAccount'' attribute in the ''Transaction'' object represents a “single” relationship (transactions belong only to one account). Generally speaking, any combinations of single and multiple references are possible within the matching relationship. Note that the ''MyTransactions'' attribute on the ''Account'' business object represents a “multiple” relationship (account may have multiple transactions) whereas the matching ''MyAccount'' attribute in the ''Transaction'' object represents a “single” relationship (transactions belong only to one account). Generally speaking, any combinations of single and multiple references are possible within the matching relationship.
  
-Matching relationships are very convenient as far as navigation between objects is concerned. In the example above once an instance of the ''Account'' object has been added to a particular ''Transaction'' in the Operation Mode the added ''Account'' will automatically have the Transaction in its list of transactions and vice versa – if an instance of a ''Transaction'' has been added to the list of transactions on the ''Account'', the ''Account'' is also automatically attached to the ''Transaction''. The corresponding forms of both the ''Account'' and ''Transaction'' objects will automatically allow navigation to the referred instances (unless presentation options are explicitly specified not to allow this – see [[docs:2500_config_apps:0700_add_edit_attributes:0500_ref_attrib#Presentation_Options_for_References|Presentation Options for References]]).+Matching relationships are very convenient as far as navigation between objects is concerned. In the example above once an instance of the ''Account'' object has been added to a particular ''Transaction'' in the Operation Mode the added ''Account'' will automatically have the Transaction in its list of transactions and vice versa – if an instance of a ''Transaction'' has been added to the list of transactions on the ''Account'', the ''Account'' is also automatically attached to the ''Transaction''. The corresponding forms of both the ''Account'' and ''Transaction'' objects will automatically allow navigation to the referred instances (unless presentation options are explicitly specified not to allow this – see [[2500_config_apps:0700_add_edit_attributes:0500_ref_attrib#Presentation_Options_for_References|Presentation Options for References]]).
  
 With non-matching relationships there are no matching attributes on the referred object. Consequently if an instance of the second object is added to the first object in the Operation Mode only the first object will know that it has references to the instance of the second object – the instance of the second object will not know that some instance of the first object refers to it. Thus navigation from the instance of the second object directly to the instance of the first object will not be possible. Note that if the reference attribute on the first object has no matching attribute in the second object it does not mean that the second object may not refer to the first object at all through its own reference (matching or non-matching). If such reference does exist it is a completely different relationship. This is shown in the example below (''FamilyMember'' object has a non-matching single relationship to its ''Family'' and the ''Family'' object has independent non-matching single relationship to the ''FamilyMember'' object – ''HeadOfFamily''): With non-matching relationships there are no matching attributes on the referred object. Consequently if an instance of the second object is added to the first object in the Operation Mode only the first object will know that it has references to the instance of the second object – the instance of the second object will not know that some instance of the first object refers to it. Thus navigation from the instance of the second object directly to the instance of the first object will not be possible. Note that if the reference attribute on the first object has no matching attribute in the second object it does not mean that the second object may not refer to the first object at all through its own reference (matching or non-matching). If such reference does exist it is a completely different relationship. This is shown in the example below (''FamilyMember'' object has a non-matching single relationship to its ''Family'' and the ''Family'' object has independent non-matching single relationship to the ''FamilyMember'' object – ''HeadOfFamily''):
Line 40: Line 40:
 The above behaviour saves the trouble of configuring rules to delete child instances explicitly. The above behaviour saves the trouble of configuring rules to delete child instances explicitly.
  
-See also: [[Working with References in the Operation Mode]].+See also: [[docs:2000_concepts:0200_basics:working_with_references_in_the_operation_mode]].
  
 ===== Video ===== ===== Video =====
-{{page>docs:5000_videos:040_relationships}}+{{page>:5000_videos:040_relationships}}