<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>idea Allow expressions to reference fields in primary AND related tables when creating a joined hosted feature layer view using add to definition in ArcGIS Online Ideas</title>
    <link>https://community.esri.com/t5/arcgis-online-ideas/allow-expressions-to-reference-fields-in-primary/idi-p/1511673</link>
    <description>&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;P&gt;When creating a joined, hosted feature layer view using "add to definition," there is the option to calculate the value of a field using the the "expression" key. This works great as long as all fields used in the expression are within a single table (e.g., the primary table). Often though, the reason for creating the join in the first place is to streamline calculations between between fields held in different tables.&lt;/P&gt;&lt;P data-unlink="true"&gt;The &lt;A href="https://developers.arcgis.com/rest/services-reference/enterprise/add-to-definition-feature-service/#primary-table" target="_self"&gt;documentation&lt;/A&gt;&amp;nbsp;for Add to definition suggest&amp;nbsp; that joins are similar in structure to SQL joins. A key paradigm in sql joins is the ability to reference all fields in the resulting table.&lt;/P&gt;&lt;P&gt;I propose that hosted feature layer joins should follow this same paradigm. Fields should be defined once, in a single "sourceLayerFields" property, rather then separately for the primary and related tables. This behavior is even suggested by the REST documentation in the definition of that property: "The list of fields in the newly created view of the joined layer.&lt;/P&gt;&lt;P&gt;I could see this potentially be solved, maintaining backwards compatibility by simply concatenating the two sourceLayerFields properties behind the scenes and then deprecating that property in relatedTables.&lt;/P&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;</description>
    <pubDate>Mon, 29 Jul 2024 15:51:34 GMT</pubDate>
    <dc:creator>jfisher</dc:creator>
    <dc:date>2024-07-29T15:51:34Z</dc:date>
    <item>
      <title>Allow expressions to reference fields in primary AND related tables when creating a joined hosted feature layer view using add to definition</title>
      <link>https://community.esri.com/t5/arcgis-online-ideas/allow-expressions-to-reference-fields-in-primary/idi-p/1511673</link>
      <description>&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;P&gt;When creating a joined, hosted feature layer view using "add to definition," there is the option to calculate the value of a field using the the "expression" key. This works great as long as all fields used in the expression are within a single table (e.g., the primary table). Often though, the reason for creating the join in the first place is to streamline calculations between between fields held in different tables.&lt;/P&gt;&lt;P data-unlink="true"&gt;The &lt;A href="https://developers.arcgis.com/rest/services-reference/enterprise/add-to-definition-feature-service/#primary-table" target="_self"&gt;documentation&lt;/A&gt;&amp;nbsp;for Add to definition suggest&amp;nbsp; that joins are similar in structure to SQL joins. A key paradigm in sql joins is the ability to reference all fields in the resulting table.&lt;/P&gt;&lt;P&gt;I propose that hosted feature layer joins should follow this same paradigm. Fields should be defined once, in a single "sourceLayerFields" property, rather then separately for the primary and related tables. This behavior is even suggested by the REST documentation in the definition of that property: "The list of fields in the newly created view of the joined layer.&lt;/P&gt;&lt;P&gt;I could see this potentially be solved, maintaining backwards compatibility by simply concatenating the two sourceLayerFields properties behind the scenes and then deprecating that property in relatedTables.&lt;/P&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;</description>
      <pubDate>Mon, 29 Jul 2024 15:51:34 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcgis-online-ideas/allow-expressions-to-reference-fields-in-primary/idi-p/1511673</guid>
      <dc:creator>jfisher</dc:creator>
      <dc:date>2024-07-29T15:51:34Z</dc:date>
    </item>
  </channel>
</rss>

