Announcement

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

  • Duplicate row briefly appears in ListGrid when saving new record (SmartGWT 6.1)

    SmartClient Version: v11.1p_2017-08-03/Enterprise Deployment (built 2017-08-03)
    Firefox 54

    I'm having an issue in my application that started appearing when upgrading from SmartGWT 6.0p to 6.1p, and I need some help figuring out what I'm doing (or not doing) that is causing this to happen.

    We have several pages in our application with "Association" ListGrids. That is, a page in which the user edits the details of a particular object (say, an "Account" for example). There are several Account fields that can be updated, as well as a ListGrid that lists Users associated with this Account.

    When adding a new User (call it Bob) to the ListGrid and then performing a Save on the full page, a duplicate "Bob" record will appear in the ListGrid right after the data is saved. This duplicate record is cosmetic only -- it doesn't actually save the duplicate record. But it is strange that this duplicate record appears in the ListGrid after the save action is committed.

    I'm sure this isn't a bug in SmartGWT because it would have been caught and fixed, so I am just wondering if something changed relating to adding data to a ListGrid, or to executing transactions using RPCManager.sendQueue that I should be aware of. I could not find the release notes for 6.1p.

  • #2
    A likely cause for this is returning data in the DSResponse for the "add" operation that doesn't match the primary key value of the record that was saved.

    By enabling the "ResultSet" logs and looking at the response data in the RPC tab of the Developer Console, you should be able to see logs of what's going on, and check for mismatches between the PK in the data being saved and response.

    It may be a subtle typing issue such as returning a String for a field that should be an integer value, or something along those lines. Some fixes in the values comparison and search code for 6.1 might have revealed a pre-existing bug in your application code along these lines.

    Comment


    • #3
      Thanks. I had a feeling it was going to be one of the issues you suggested. But looking at the DSRequest and the DSResponse in the RPC tab of the Developer Console, I don't see anything that stands out as being mismatched. I also compared the DSRequest/Response to that of the DSRequest/Response in the current SmartGWT 6.0 version of our application, and there's no difference [not that you said there would be; but I just wanted to check]. This issue only happens in local grids I should mention, where no data in the grid is actually saved until the user clicks "Save" at the bottom of the page.

      Since I have spent several days trying to resolve this to no avail, our team is postponing our upgrade to 6.1 to make way for higher priority features/fixes. If you see any abnormalities in the DSRequest / DSResponse objects please let me know. These are for the "add" operation to associate a "Local Element" to a "Short Title.

      Request:
      Code:
      {
          dataSource:"ShortTitleLocalElement", 
          operationType:"add", 
          operationId:"addLocalElementsToNewShortTitle", 
          data:{
              local_element_id:5
          }, 
          textMatchStyle:"exact", 
          willHandleError:true, 
          showPrompt:true, 
          oldValues:{
              local_element_id:5
          }, 
          requestId:"ShortTitleLocalElement$627336", 
          fallbackToEval:false, 
          lastClientEventThreadCode:"MDN0", 
          bypassCache:true, 
          dataProtocol:"getParams"
      }
      Response
      Code:
      {
          affectedRows:1, 
          data:[
              {
                  display_local_element_id:"111111", 
                  local_element_name:"Account 1", 
                  business_phone:"(858) 826-1123", 
                  last_updated_by:"JONES.MATT.1234567890", 
                  short_title_id:50, 
                  business_fax:"(619) 752-4595", 
                  local_element_id:5, 
                  last_updated_date:"2017-08-09T01:35:56.063", 
                  email:"army@gmail.com"
              }
          ], 
          invalidateCache:false, 
          isDSResponse:true, 
          operationType:"add", 
          queueStatus:0, 
          status:0
      }

      Comment


      • #4
        Did you look at the ResultSet logs? That was our first suggestion, and it should tell you exactly what is going on in the cache. That would actually be the starting point for any investigation of cache updates going awry.

        Comment


        • #5
          Ah ok, I misread that sentence and I was only looking in the RPC tab.
          So I've set ResultSet logging to DEBUG and I see some very different output between the 6.0 version and the 6.1 version.

          Saving the data in that page with SmartGWT 6.0:
          Code:
          16:38:24.907:XRP2:INFO:ResultSet:isc_ResultSet_7 (dataSource: Tasks, created by: isc_TaskMenuPopup_2_0):Invalidating cache
          16:38:24.910:XRP2:INFO:ResultSet:isc_ResultSet_7 (dataSource: Tasks, created by: isc_TaskMenuPopup_2_0):setCriteria: filter criteria changed, invalidating cache
          16:38:24.911:XRP2:INFO:ResultSet:isc_ResultSet_7 (dataSource: Tasks, created by: isc_TaskMenuPopup_2_0):Invalidating cache
          16:38:24.913:XRP2:DEBUG:ResultSet:isc_ResultSet_7 (dataSource: Tasks, created by: isc_TaskMenuPopup_2_0):getRange(0,1), cache check: 0,37 firstMissingRow: 0 lastMissingRow: 37
          16:38:24.915:XRP2:DEBUG:ResultSet:isc_ResultSet_7 (dataSource: Tasks, created by: isc_TaskMenuPopup_2_0):getRange: guessing forward scrolling
          16:38:24.917:XRP2:INFO:ResultSet:isc_ResultSet_7 (dataSource: Tasks, created by: isc_TaskMenuPopup_2_0):getRange(0, 1) will fetch from 0 to 75
          16:38:24.918:XRP2:INFO:ResultSet:isc_ResultSet_7 (dataSource: Tasks, created by: isc_TaskMenuPopup_2_0):fetching rows 0,75 from server
          16:38:24.946:XRP5:INFO:ResultSet:isc_ResultSet_7 (dataSource: Tasks, created by: isc_TaskMenuPopup_2_0):Received 0 records from server
          16:38:24.947:XRP5:DEBUG:ResultSet:isc_ResultSet_7 (dataSource: Tasks, created by: isc_TaskMenuPopup_2_0):full length set to: 0
          16:38:24.948:XRP5:DEBUG:ResultSet:isc_ResultSet_7 (dataSource: Tasks, created by: isc_TaskMenuPopup_2_0):integrating 0 rows into cache at position 0
          16:38:24.949:XRP5:INFO:ResultSet:isc_ResultSet_7 (dataSource: Tasks, created by: isc_TaskMenuPopup_2_0):Fetch request returned range 0,0 differs from requested range 0,75. Assuming client/server batch size mismatch and clearing loading markers greater than 0
          16:38:24.950:XRP5:INFO:ResultSet:isc_ResultSet_7 (dataSource: Tasks, created by: isc_TaskMenuPopup_2_0):cached 0 rows, from 0 to 0 (0 total rows, 0 cached)
          16:38:24.951:XRP5:INFO:ResultSet:isc_ResultSet_7 (dataSource: Tasks, created by: isc_TaskMenuPopup_2_0):Cache for entire DataSource complete
          16:38:24.953:XRP5:DEBUG:ResultSet:isc_ResultSet_7 (dataSource: Tasks, created by: isc_TaskMenuPopup_2_0):getRange(0, 0): returning empty list
          16:38:24.954:XRP5:DEBUG:ResultSet:isc_ResultSet_7 (dataSource: Tasks, created by: isc_TaskMenuPopup_2_0):getRange(0, 0): returning empty list
          Looks pretty normal.

          With 6.1
          Code:
          16:53:43.600:XRP8:DEBUG:ResultSet:isc_ResultSet_28 (dataSource: ShortTitleLocalElement, created by: undefined):dataSource data changed firing
          16:53:43.601:XRP8:INFO:ResultSet:isc_ResultSet_28 (dataSource: ShortTitleLocalElement, created by: undefined):updating cache in place after operationType: add, allMatchingRowsCached true
          16:53:43.605:XRP8:INFO:ResultSet:isc_ResultSet_28 (dataSource: ShortTitleLocalElement, created by: undefined):Updating cache: operationType 'add' (no componentID) ,1 rows update data:
          [
          {display_local_element_id: "111111",
          local_element_name: "Account 1",
          business_phone: "(858) 826-1123",
          last_updated_by: "JONES.MATT.1234567890",
          short_title_id: 24,
          business_fax: "(619) 752-4595",
          local_element_id: 5,
          last_updated_date: Date(08/10/2017),
          email: "army@gmail.com"}
          ]
          16:53:43.607:XRP8:DEBUG:ResultSet:isc_ResultSet_29 (dataSource: ShortTitleLocalElement, created by: undefined):dataSource data changed firing
          16:53:43.608:XRP8:INFO:ResultSet:isc_ResultSet_29 (dataSource: ShortTitleLocalElement, created by: undefined):updating cache in place after operationType: add, allMatchingRowsCached true
          16:53:43.609:XRP8:INFO:ResultSet:isc_ResultSet_29 (dataSource: ShortTitleLocalElement, created by: undefined):Updating cache: operationType 'add' (no componentID) ,1 rows update data:
          [
          {display_local_element_id: "111111",
          local_element_name: "Account 1",
          business_phone: "(858) 826-1123",
          last_updated_by: "JONES.MATT.1234567890",
          short_title_id: 24,
          business_fax: "(619) 752-4595",
          local_element_id: 5,
          last_updated_date: Date(08/10/2017),
          email: "army@gmail.com"}
          ]
          16:53:43.610:XRP8:DEBUG:ResultSet:isc_ResultSet_30 (dataSource: ShortTitleLocalElement, created by: undefined):dataSource data changed firing
          16:53:43.610:XRP8:INFO:ResultSet:isc_ResultSet_30 (dataSource: ShortTitleLocalElement, created by: undefined):updating cache in place after operationType: add, allMatchingRowsCached true
          16:53:43.611:XRP8:INFO:ResultSet:isc_ResultSet_30 (dataSource: ShortTitleLocalElement, created by: undefined):Updating cache: operationType 'add' (no componentID) ,1 rows update data:
          [
          {display_local_element_id: "111111",
          local_element_name: "Account 1",
          business_phone: "(858) 826-1123",
          last_updated_by: "JONES.MATT.1234567890",
          short_title_id: 24,
          business_fax: "(619) 752-4595",
          local_element_id: 5,
          last_updated_date: Date(08/10/2017),
          email: "army@gmail.com"}
          ]
          16:53:43.612:XRP8:DEBUG:ResultSet:isc_ResultSet_31 (dataSource: ShortTitleLocalElement, created by: undefined):dataSource data changed firing
          16:53:43.612:XRP8:INFO:ResultSet:isc_ResultSet_31 (dataSource: ShortTitleLocalElement, created by: undefined):updating cache in place after operationType: add, allMatchingRowsCached true
          16:53:43.613:XRP8:INFO:ResultSet:isc_ResultSet_31 (dataSource: ShortTitleLocalElement, created by: undefined):Updating cache: operationType 'add' (no componentID) ,1 rows update data:
          [
          {display_local_element_id: "111111",
          local_element_name: "Account 1",
          business_phone: "(858) 826-1123",
          last_updated_by: "JONES.MATT.1234567890",
          short_title_id: 24,
          business_fax: "(619) 752-4595",
          local_element_id: 5,
          last_updated_date: Date(08/10/2017),
          email: "army@gmail.com"}
          ]
          Whoa, a bunch of cache updates that all look the same.
          You can see that there are 4 cache updates, but every subsequent time I perform this same operation, more cache updates get appended. That is, if I undo this association and then re-do it, there are now 7 cache updates showing in the ResultSet logs instead of 4. If I re-do it again, there are 13, and then 19, and then so on. It's like each time it adds +1 to the number of cache updates that were performed the previous time.

          What do you think might be happening here? Why would there be so many cache updates?

          Comment


          • #6
            You've shared so little information about your code that it's hard to speculate. One possibility would be that you are repeatedly registering an event handler that only needs to be registered once, so your code ends up firing one extra time each time the event fires.

            An easy way to get more information is to use SC.traceLogMessage() to get a stack trace for each of the update logs. That will show you the calling code.

            Also, are you hand-creating ResultSets via "new ResultSet()"? And are you using DataSource.updateCaches()?

            Comment

            Working...
            X