Announcement

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

    Databound Timeline with autofetchdata causes duplicate server fetch

    build 5.0-p20150808

    Please consider my Timeline extension:
    Code:
    public static final int[] workdays = {1,2,3,4,5,6,7};
    
        public ScheduleTimeline(boolean canEditEvents, String helpUrl) {
            super();        
            setWorkdays(workdays);
            setCanEditEvents(canEditEvents);
    
            setCanEditLane(false);
            setShowEventDescriptions(true);
                   setDataPageSize(200);
    
            setStartDateField("inTime");
            setEndDateField("outTime");
            setNameField(NubaClientServerConstants.FIELD_LOCATIONNAME);
            setShowEventDescriptions(true);
            setDescriptionField("note");
            setMinLaneWidth(130);
            setTimeFormatter(TimeDisplayFormat.TOSHORTPADDED24HOURTIME);
    
            setHeaderLevels(createHeaderLevels());
            setLaneFields(new ListGridField[]{new ListGridField("title", CommonConstants.constants.reportUser(), CommonConstants.FIELD_WIDTH_REPORTERNAME)});
            setLaneEventPadding(2);
            setEventStyleName("eventWindow");
            setCanRemoveEvents(false);
            setDataSource(DataSource.get("schedule"));
            /*Date begin = new Date();
            Date end = new Date();
            CalendarUtil.addMonthsToDate(end, 1);
            setStartDate(begin);
            setEndDate(end);*/
            setAutoFetchData(true);
        }
    It's ds.xml is defined as a spring datasource, so i have a Spring bean with a fetch method that's being called.

    Whenever my components loads, it fetches one month of events from my server, which it does. However, the first fetch, rows 0-200, is always called twice!

    As you can see, the calls differ in that there's a sliiightly altered 'end' date, so i was suspecting it had something to do with me calling the setstartdate and setenddate before setting "autofetchdata", but as you can see in the code, i have commented it out, and rows 0-200 are still being fetched twice!

    I'm kind of at a loss here, so i'm hoping that you can find some issue your end...




    see my log transcipt here:

    Code:
    2015-08-29 14:24:38.006 DEBUG c.k.n.s.w.ScheduleWebService - fetch!;begin;2015-08-29T00:00:00.000+02:00;end;2015-09-18T23:59:59.999+02:00;startrow;0;endrow;200;limit;200;totalRows;400;reporterid;null;locationId;null
    2015-08-29 14:24:38.006 DEBUG c.k.n.s.w.ScheduleWebService - fetch!;begin;2015-08-29T00:00:00.000+02:00;end;2015-09-19T00:00:00.000+02:00;startrow;0;endrow;200;limit;200;totalRows;400;reporterid;null;locationId;null
    2015-08-29 14:24:42.051 DEBUG c.k.n.s.w.ScheduleWebService - fetch!;begin;2015-08-29T00:00:00.000+02:00;end;2015-09-19T00:00:00.000+02:00;startrow;200;endrow;400;limit;200;totalRows;600;reporterid;null;locationId;null
    2015-08-29 14:24:42.253 DEBUG c.k.n.s.w.ScheduleWebService - fetch!;begin;2015-08-29T00:00:00.000+02:00;end;2015-09-19T00:00:00.000+02:00;startrow;400;endrow;401;limit;200;totalRows;401;reporterid;null;locationId;null

    #2
    Try making setStartDate()/EndDate() the very first calls, and make sure you do this and any other configuration before you cause the widget to draw or add it to a parent or Layout.

    Comment


      #3
      Thanks for responding so quickly!

      Well, as i mentioned, i have commented out the setstart/enddate, so that i'm not calling them at all right now, and i still get the duplicate calls.

      Comment


        #4
        To illustrate this, please consider my server-side log when i do NOT call the setDates-methods.

        The reason for my date-calls is that i want the period of one month. (and you can see that it is one month in my post above)

        Now that i do not set anything, my server gets called with the default three-week-period.

        But i STILL get the multiple call with slightly changed end date.

        Code:
        2015-08-30 10:49:56.558 DEBUG c.k.n.s.w.ScheduleWebService - fetch!;begin;2015-08-30T00:00:00.000+02:00;end;2015-09-20T00:00:00.000+02:00;startrow;0;endrow;200;limit;200;totalRows;400;reporterid;null;locationId;null
        2015-08-30 10:49:56.558 DEBUG c.k.n.s.w.ScheduleWebService - fetch!;begin;2015-08-30T00:00:00.000+02:00;end;2015-09-19T23:59:59.999+02:00;startrow;0;endrow;200;limit;200;totalRows;400;reporterid;null;locationId;null

        Comment


          #5
          And if you just switch off autoFetchData, does everything start to work as you expect? That is, do you still get the fetch you expect, but only once?

          Comment


            #6
            Well, no, then i don't get any fetch. Even if i set the dates, there's no fetch.

            Sorry if i'm asking the obvious - but if i turn off autofetchdata, wouldn't i have to call fetch on the timeline myself in order for it to fetch data?

            (Which would mean putting together that complex criteria with start- and enddates just like the timeline does...)

            Comment


              #7
              I am also getting a 2nd fetch operation after updating to SmartClient Version: v10.0p_2015-08-28/Pro Deployment (built 2015-08-28)

              autofetchdata is false and I fetch via a call to timeline.fetchData();

              The new fetch operation has criteria with start and end dates which the normal fetch operation doesn't have.

              Code:
              {
                  dataSource:"project_resource_overview", 
                  operationType:"fetch", 
                  componentId:"isc_Timeline_0", 
                  data:{
                      sessionId:"e408e683-fd3e-4a72-9e0e-21286acaa324", 
                      operator:"and", 
                      criteria:[
                          {
                              fieldName:"startDate", 
                              operator:"lessThan", 
                              value:"2015-09-28T22:00:00.000"
                          }, 
                          {
                              fieldName:"endDate", 
                              operator:"greaterThan", 
                              value:"2015-08-30T22:00:00.000"
                          }
                      ]
                  }, 
                  startRow:0, 
                  endRow:75, 
                  textMatchStyle:"exact", 
                  resultSet:[ResultSet ID:isc_ResultSet_0 (dataSource: project_resource_overview, created by: isc_Timeline_0)], 
                  callback:{
                      caller:[ResultSet ID:isc_ResultSet_0 (dataSource: project_resource_overview, created by: isc_Timeline_0)], 
                      methodName:"fetchRemoteDataReply"
                  }, 
                  willHandleError:true, 
                  showPrompt:true, 
                  prompt:"Finding Records that match your criteria...", 
                  oldValues:{
                      sessionId:"e408e683-fd3e-4a72-9e0e-21286acaa324", 
                      operator:"and", 
                      criteria:[
                          {
                              fieldName:"startDate", 
                              operator:"lessThan", 
                              value:"2015-09-28T22:00:00.000"
                          }, 
                          {
                              fieldName:"endDate", 
                              operator:"greaterThan", 
                              value:"2015-08-30T22:00:00.000"
                          }
                      ]
                  }, 
                  requestId:"project_resource_overview$62713", 
                  internalClientContext:{
                      requestIndex:2
                  }, 
                  fallbackToEval:false, 
                  lastClientEventThreadCode:"XRP6[E0]", 
                  bypassCache:true
              }

              Comment


                #8
                When a refreshEvents() runs on a CalendarView, it fetches everything from the recordSet or data-array assigned to the parent Calendar.

                When the accessible range calendarView changes, a fetch is made against the parent data - and, for Timelines, this fetch includes the dates for the accessible range.

                If your criteria affects nothing but dates, you can just make your Timeline autoFetchData:true, or call setTimelineRange(), rather than calling fetchData. It will always select events for just the dates it can actually affect.

                If you don't want the date-criteria to be automatically included by the timeline, try using the autoChild system to set TimelineView.setAttribute("fetchMode", "all") - this is not a fully supported mechanism at the moment, but if it gives you the behavior you're after, we can look at whether the implementation can be completed for 5.1.

                Comment


                  #9
                  Okay so I changed it to use autofetchdata instead of a manual fetch call, but it still sends 2 fetch requests. The only difference is that now they both contain start/end dates in their criteria.

                  I'm using custom datasources so I can just choose not to use the criteria, that is not the problem. I just want it to only fetch 1 time.

                  Another problem with these new fetch requests is my sessionId.
                  For all my datasources I use DataSource.setDefaultParams to add a sessionId to all datasource calls.
                  On the server I check if the session is still legal before continuing. I get the sessionId via DSRequest.getCriteria().get("sessionId") and this has worked for all my datasources so far.
                  But for some reason with the "new" fetch operation when I look in getCriteria() there is no sessionId.

                  This is what it looks like when I debug in the datasource.
                  Code:
                  {criteria=[{fieldName=startDate, operator=lessThan, value=Mon Sep 28 23:59:59 CEST 2015}, {fieldName=endDate, operator=greaterThan, value=Mon Aug 31 00:00:00 CEST 2015}], operator=and, _constructor=AdvancedCriteria}
                  If I look in DSRequest.getOldValues() I can find it, but I dont know why these fetch requests are behaving differently from all the others.


                  Here are the DSRequests from the Developer Console for the 2 fetch requests:
                  Request 1:
                  Code:
                  {
                      dataSource:"project_resource_overview", 
                      operationType:"fetch", 
                      componentId:"isc_Timeline_0", 
                      data:{
                          sessionId:"7e601b5c-0cdb-4793-9967-8fffa9bdc8ee", 
                          operator:"and", 
                          criteria:[
                              {
                                  fieldName:"startDate", 
                                  operator:"lessThan", 
                                  value:"2015-09-28T21:59:59.999"
                              }, 
                              {
                                  fieldName:"endDate", 
                                  operator:"greaterThan", 
                                  value:"2015-08-30T22:00:00.000"
                              }
                          ]
                      }, 
                      startRow:0, 
                      endRow:75, 
                      textMatchStyle:"exact", 
                      resultSet:[ResultSet ID:isc_ResultSet_0 (dataSource: project_resource_overview, created by: isc_Timeline_0)], 
                      callback:{
                          caller:[ResultSet ID:isc_ResultSet_0 (dataSource: project_resource_overview, created by: isc_Timeline_0)], 
                          methodName:"fetchRemoteDataReply"
                      }, 
                      willHandleError:true, 
                      showPrompt:true, 
                      prompt:"Finding Records that match your criteria...", 
                      oldValues:{
                          sessionId:"7e601b5c-0cdb-4793-9967-8fffa9bdc8ee", 
                          operator:"and", 
                          criteria:[
                              {
                                  fieldName:"startDate", 
                                  operator:"lessThan", 
                                  value:"2015-09-28T21:59:59.999"
                              }, 
                              {
                                  fieldName:"endDate", 
                                  operator:"greaterThan", 
                                  value:"2015-08-30T22:00:00.000"
                              }
                          ]
                      }, 
                      requestId:"project_resource_overview$62712", 
                      internalClientContext:{
                          requestIndex:1
                      }, 
                      fallbackToEval:false, 
                      lastClientEventThreadCode:"XRP5[E0]", 
                      bypassCache:true
                  }
                  Request 2:
                  Code:
                  {
                      dataSource:"project_resource_overview", 
                      operationType:"fetch", 
                      componentId:"isc_Timeline_0", 
                      data:{
                          sessionId:"7e601b5c-0cdb-4793-9967-8fffa9bdc8ee", 
                          operator:"and", 
                          criteria:[
                              {
                                  fieldName:"startDate", 
                                  operator:"lessThan", 
                                  value:"2015-09-28T22:00:00.000"
                              }, 
                              {
                                  fieldName:"endDate", 
                                  operator:"greaterThan", 
                                  value:"2015-08-30T22:00:00.000"
                              }
                          ]
                      }, 
                      startRow:0, 
                      endRow:75, 
                      textMatchStyle:"exact", 
                      resultSet:[ResultSet ID:isc_ResultSet_0 (dataSource: project_resource_overview, created by: isc_Timeline_0)], 
                      callback:{
                          caller:[ResultSet ID:isc_ResultSet_0 (dataSource: project_resource_overview, created by: isc_Timeline_0)], 
                          methodName:"fetchRemoteDataReply"
                      }, 
                      willHandleError:true, 
                      showPrompt:true, 
                      prompt:"Finding Records that match your criteria...", 
                      oldValues:{
                          sessionId:"7e601b5c-0cdb-4793-9967-8fffa9bdc8ee", 
                          operator:"and", 
                          criteria:[
                              {
                                  fieldName:"startDate", 
                                  operator:"lessThan", 
                                  value:"2015-09-28T22:00:00.000"
                              }, 
                              {
                                  fieldName:"endDate", 
                                  operator:"greaterThan", 
                                  value:"2015-08-30T22:00:00.000"
                              }
                          ]
                      }, 
                      requestId:"project_resource_overview$62713", 
                      internalClientContext:{
                          requestIndex:2
                      }, 
                      fallbackToEval:false, 
                      lastClientEventThreadCode:"XRP5[E0]", 
                      bypassCache:true
                  }
                  As you can see, they are almost identical except for the startDate which is a millisecond different, and the requestIndex.
                  You can also see that the sessionId is present in the data so I don't understand why it disappears on the server.

                  Comment


                    #10
                    A quick note that we see this behavior and we're looking into it. We'll update here when we have more information.

                    Comment


                      #11
                      We've made some enhancements to Calendar/Timeline databinding.

                      1) fixed initial fetch behavior (including duplicate initial fetches, no initial fetch, and fetches without proper criteria)

                      2) regular criteria, manually applied via fetchData() or setCriteria() for example, is now retained for fetches initiated automatically by the "next" and "previous" buttons, or by calls to setTimelineRange()

                      3) date-range criteria is applied, as it always was, according to the accesible range of the calling CalendarView- but it is now applied at the last minute to any fetch, and will correctly retain any non date-range criteria supplied by the dev, while overwriting any date-range criteria with the range from the calendar view.

                      Note that this mechanism is still incomplete, so APIs to completely configure it are not yet public.

                      However, these changes should address all of the issues reported in this thread, as well as enabling general DataBoundComponent criteria-handling for Calendars.

                      Please retest your issues with a build dated September 3 or later.
                      Last edited by Isomorphic; 2 Sep 2015, 04:16.

                      Comment


                        #12
                        Tried for the september 3 build, and i can conform that it nolonger performs duplicate fetches. Great stuff!


                        However, it seems you have introduced a new bug. The calendar string on the timeline control bar is displaying kind of strange text.

                        Please examine the attached screenshot. the 'from' date *always* shows '2009-08-31'. (Also, the "through" text resource is still not i18n).
                        Attached Files

                        Comment


                          #13
                          After updating, the timeline no longer fetches twice :), but my problem with the sessionId still persists :(.

                          Comment


                            #14
                            @mathais - the string format has been repaired and will hit builds in the next day or two - it's part of a set of fixes awaiting being tested - note that i18n support is not yet present; we're re-considering the approach being used and will let you know what comes of that.

                            Niels_EMP - we'll take a look and get back to you when we have more information on your sessionId issue

                            Comment


                              #15
                              Any progress on my sessionId issue?

                              Comment

                              Working...
                              X