Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Auto client fetch to related datasource

    Hi,

    I'm using smartgwt-power-3.1-p20130712.

    I have 2 SQL datasources like below:
    Code:
    <DataSource ID="mseContacts" serverType="sql" dbName="xxx" tableName="yyy" autoJoinTransactions="true">
        <fields>
            <field name="id" type="text" hidden="true" escapeHTML="true" nativeName="ID" primaryKey="true" />        
       ...
            <field name="customerId" type="text" hidden="true" escapeHTML="true" nativeName="CUSTOMER_ID" foreignKey="mseCustomer.id"/>
        </fields>		
    </DataSource>
    
    
    <DataSource ID="mseCustomer" serverType="sql" dbName="xxx" tableName="zzz" autoJoinTransactions="true" > 	
        <fields>    
            <field name="id" type="text" nativeName="ID" primaryKey="true" hidden="true" operator="equals" escapeHTML="true"/>
    		...
        </fields>		
    </DataSource>
    and I fetch by mseContacts.id one row in a form, but immediately is triggered a fetch to mseCustomer with the related id.
    My question is why is the later fetch done to mseCustomer datasource?
    And in which situations such fetches should be done automatically?
    See also the attached picture from the dev console.
    One other strange thing is that request/response of the later fetch to mseCustomer is not shown in the dev console.
    Attached Files

    #2
    This is a consequence of FormItem.fetchMissingValues, because a display value is needed so that the customerId is not shown in the raw. See the fetchMissingValues doc for how to control or possibly avoid this fetch.

    Comment


      #3
      Setting to false that property solved the problem:
      customerIdItem.setFetchMissingValues(false);
      But still, the customerIdItem has no option datasource, nor a displayValue.
      It still looks strange to me based on the setFetchMissingValues documentation. Maybe you could clarify that.

      Comment


        #4
        optionDataSource is automatically derived from your foreignKey setting in this instance.

        Comment


          #5
          Is that documented somewhere? I didn't find it.

          Also I don't need an optionDatasource in this case.
          That customerId field is hidden, so I also don't need an displayField attribute, although I could use one that is already included from the related datasource.

          What is more apropiate: to setFetchMissingValues(false) or define displayField attribute?

          Comment


            #6
            If it were hidden and remained hidden, the fetchMissingValues behavior would not happen because no FormItem would ever have been created for the field.

            Perhaps you have some kind of bug in your code where you apply a set of fields that makes the field visibly briefly, then apply another set of fields that makes it invisible again?

            Comment


              #7
              The form item is created but also setVisible(false) is used.

              Comment


                #8
                OK, fetchMissingValues does not currently try to delay fetching a displayValue until a FormItem is shown (and it's not clear that it should; doing so would mean the ID would be briefly visible to the user during the fetch).

                We don't know why you've created a FormItem for a field that isn't visible and presumably never will be. The best approach is probably to avoid doing this, then the fetchMissingValues behavior will never be triggered.

                Second best would be to set fetchMissingValues to false (no performance impact).

                Setting up a displayField would be the worst of the mentioned approaches since you'd actually need to provide a value for the displayField.

                Comment


                  #9
                  I create a new "contact" entity for a "customer" using a form. The customerId FormItem is prefilled and hidden and has to be sent to the server.
                  Is that a wrong approach?

                  Comment


                    #10
                    Yes, that's the wrong approach - no FormItem is needed in order to track a hidden value. The form will maintain a value for the field even if there's no item, so having an extra item just degrades performance.

                    Comment

                    Working...
                    X