locked
LS2013 - interesting caching observation, is this a bug? RRS feed

  • Question

  • Consider the following example scenario in the HTML client:

    1/ Have a default home screen listing Orders using a List view

    2/ Add a Tap event to list view and open a read-only Order preview screen as a dialog

    3/ Read-only Order preview screen has two tabs: Header and Details (where header shows order header and details show detail items as List)

    4/ Select any order on main screen, tap item to pop up Order preview screen, switch to Details tab and view details

    5/ Switch back to main screen and view a different Order - all good to this point

    6/ Using SQL Management studio or another program, edit any of the order lines

    7/ Switch back to still running HTML client and select the order that was just edited and tap it to open preview screen

    8/ Switch to Details tab to view details - problem, you still see the old version (seems to have cached that on the client)

    9/ Use fidler or Chrome developer tools to look at the network traffic when you repeat steps 7 & 8 - the correct data is indeed coming back from the backend, it is just not displaying it

    10/ Ctrl-F5 to reload HTML app and repeat steps 7 & 8, now it works correctly

    This does not seem correct to me. Is this a bug in LS2013 HTML client preview?

    Additional information:

    • Running under VS2013 in debug mode (haven't tried to deploy and check)
    • Data source is actually a RIA service, but that should not matter as the data is coming back correctly
    • There is no association set up between orders and Order Details (Order Details is just a filtered query)
    • This part of the app is read-only so there is no editing taking place at all
    • Happens in both IE10 and Chrome 28.0.1500.95

    Thoughts?


    Regards, Xander. My Blog

    • Edited by novascape Monday, August 5, 2013 9:35 PM additional clarification
    Monday, August 5, 2013 10:37 AM

Answers

  • Hi all,

    If I understand the scenario correctly, then this is (unfortunately) not a bug in the product. It is a behavior that was a known limitation in the first HTML client release, and while we added data refresh capabilities in subsequent releases, that was not made the default for compatibility reasons.

    Initially, the HTML client supported exactly one merge option, which describes how data queried from the server is merged with the data context on the client. The merge option we supported was "AppendOnly", which basically means that new entities not yet in the data context are added, but any existing entities in the data context remain untouched even if new data came from the server. Xander, that is why you are seeing new data come over the network but this data is not shown in the UI.

    While this seems like a poor merge option, it's actually the safest we (as a general runtime) could implement initially. It matches the default that Entity Framework provides (see this link). However, for many scenarios, it isn't a great option, so we introduced a second merge option for VS 2013. This one, called "UnchangedOnly", has all the behavior of AppendOnly but also refreshes the data in entities previously loaded on the client if they are currently unchanged (we don't want to touch modified entities as that would affect the correctness of our concurrency checking). Collection refresh utilizes this merge option.

    The UnchangedOnly merge option matches the behavior we provided for the Silverlight client, and we believe it provides the most desirable behavior for the majority of cases. However, since we initially shipped with AppendOnly as the only merge option, we need to plan how to change the default without affecting existing applications. We are actively discussing how to handle these kinds of compatibility issues in a manner that doesn't stop us from making behavioral changes between versions. So, you can expect this to be addressed in the future.

    Hopefully this explains the behavior you are seeing, and why it is currently the expected behavior. My suggestion today would be to add a "Refresh" button to your tab that shows the list of order lines, so that the end user can manually refresh the results if he/she believes them to be out of date. I'm surprised actually that inserting a call to refresh the collection in the created or postRender events didn't solve the problem. That would be another approach that should work. If it doesn't, let's figure out what's going on there.


    Visual Studio LightSwitch Team

    • Proposed as answer by LightSwitch Team Friday, October 18, 2013 7:21 PM
    • Unproposed as answer by novascape Saturday, October 19, 2013 1:51 AM
    • Marked as answer by novascape Saturday, October 19, 2013 2:16 AM
    Friday, October 18, 2013 4:10 PM

All replies

  • Thanks Michael, but in the above case I believe it is a bug, unless someone can explain to me why it works like that.

    I can understand in your example why the visual collection needs to be refreshed after the dialog closes to reflect the changes, but that is not the scenario in my case at all. 

    In my case these is no association between the Orders and Order Lines (the real example is not Orders, just using that to explain) and every time the dialog is shown and the Order Lines tab is selected, a new filtered query is fired and the correct fresh data is indeed returned from the server.

    Given that the the filtered query is only executed once you select the Order Lines tab, one would have to find a way to refresh() the query somehow when the tab is selected. Given that this is a lazy loading query (being on the second tab) you would not want to refresh() it if not required.  There is no onTabChanged() built-in event that I know of, so will need some experimentation.

    My example above over complicates the issue if I think about it some more. Although I've not tried this, I believe a simple tap event on the main screen with a dialog that opens and immediately lists the order lines only (based off a filtered query where the OrderId is passed into the dialog as a parameter) will show the same problem.

    This is going to be problematic in real world applications as we cannot expect developers to have to put all these refreshes() all over the place to ensure that they don't display stale data.

    But then again, maybe I'm missing something fairly simple here!


    Regards, Xander. My Blog

    Monday, August 5, 2013 10:01 PM
  • Ok, this is weird, I just created a small example repro project against the Northwind database using the [Orders] table and the [Orders Details Extended] view (so as to not have an association) and it works fine! I tested this with the dialog with and without tabs (i.e. with and without lazy loading) and both work.

    I will have to try and ascertain why my real example doesn't. I might add a RIA service into the sample Northwind example just to rule that out as the cause (although I cannot see how that would be the cause, given that I can see the correct data coming back from the backend).

    Hmmm...


    Regards, Xander. My Blog

    • Edited by novascape Monday, August 5, 2013 10:32 PM clarification
    Monday, August 5, 2013 10:30 PM
  • FWIW, I have inserted a screen.Collection.refresh() into the .created() event of the dialog as well as into the relevant Tab _postRender() event of my real app and neither of those fix the issue.

    I'm actually glad this didn't fix it, as a .refresh() should not be required in this case.

    It does appear that the order Details parameterized query is executing in "Append Only" mode by default. In other words, it will show newly added entities, but not display updated entities.  

    The only way to see the updated data is to reload the web page (i.e. the app).


    Regards, Xander. My Blog

    • Edited by novascape Monday, August 5, 2013 11:52 PM clarification
    Monday, August 5, 2013 11:45 PM
  • This problem can be crystallized down to the following question:

    Under what circumstances would a parameterized query, executed each time when opening a dialog, correctly show newly added entities, but only show a cached version of the existing entities, despite the correct latest version of those existing entities being returned from the server? 

    And calling .refresh() should not be the answer as the query is executed every time the dialog is opened.

    Anyone from the LS Team?

    I'm happy to wait for the next release if this is indeed a bug or the behavior will be changed, I just don't want to waste time mucking about with this if that is the case.

     

    Regards, Xander. My Blog

    • Edited by novascape Tuesday, August 6, 2013 9:26 AM clarification
    Tuesday, August 6, 2013 12:06 AM
  • Hi novascap

    Thank you for raising this issue to us through LightSwitch forum. We definitely hear your frustration on this issue. We actively monitor forum conversations in an effort to receive feedback that helps us continually improve our products, so we have logged this feedback accordingly.

    You can also consider submitting this issue to Microsoft Connect feedback LightSwitch portal (https://connect.microsoft.com/site1231), Microsoft engineers will evaluate them seriously,

    Best regards


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    • Marked as answer by Angie Xu Friday, August 23, 2013 1:40 AM
    • Unmarked as answer by novascape Monday, September 16, 2013 9:42 AM
    Tuesday, August 20, 2013 5:32 AM
  • Thanks Angie for logging this feedback with the team.

    Regards


    Regards, Xander. My Blog

    Friday, August 23, 2013 3:17 AM
  • Alas, this issue still exists in VS2013 RC...

    Just to confirm again, if you look at the Network Response Body of the data coming back from the server it contains the correct updated data but it simply does not display the updated data.

    Request:

    http://localhost:30739/Cratos.svc/GetNotesForParty()?partyId=18761&$top=45

    Correct Response (that is not displayed):

    {

    "odata.metadata":"http://localhost:30739/Cratos.svc/$metadata#NoteModels","value":[{"EntityLinkId":0,"Subject":null,"Contents":"a4 Person note for <b>DMO-00005</b> When you create pictures, charts, or diagrams, they also coordinate with your current document look. You can easily change the formatting of selected text in the document text by choosing a look for the selected text from the Quick Styles gallery on the Home tab. \r\n\r\nYou can also format text directly by using the other controls on the Home tab. Most controls offer a choice of using the look from the current theme or using a format that you specify directly.\r\n\r\nAnd the <b>final third paragraph</b>, you can easily change the formatting of selected text in the document text by choosing a look for the selected text from the Quick Styles gallery on the Home tab. You can easily change the formatting of selected text in the document text by choosing a look for the selected text from the Quick Styles gallery on the Home tab. Plus more text.\r\n","Id":35622,"UserNameCreated":"Xander","UserNameEdited":"Xander","DateCreatedUtc":"2013-08-05T08:43:33.613","DateEditedUtc":"2013-09-16T09:36:28.71","Stamp":"AAAAAALrKXM=","HasConcurrencyError":false,"HasError":false,"ErrorMessage":false,"ContentType":"text/plain"}]}


    Regards, Xander. My Blog


    • Edited by novascape Monday, September 16, 2013 9:48 AM added code
    Monday, September 16, 2013 9:45 AM
  • This issue is still present in the release version of VS2013. 

    Regards, Xander. My Blog

    Friday, October 18, 2013 12:04 AM
  • I can only laugh at the "Log it with Microsoft Connect" suggestion.

    This has been an issue since VS 2012 where data is cached, it's extremely frustrating when you are sharing an app between more than one person and you have no faith in the data consistency at the end of the day.

    Would you run your business like that ?

    Friday, October 18, 2013 10:44 AM
  • Hi all,

    If I understand the scenario correctly, then this is (unfortunately) not a bug in the product. It is a behavior that was a known limitation in the first HTML client release, and while we added data refresh capabilities in subsequent releases, that was not made the default for compatibility reasons.

    Initially, the HTML client supported exactly one merge option, which describes how data queried from the server is merged with the data context on the client. The merge option we supported was "AppendOnly", which basically means that new entities not yet in the data context are added, but any existing entities in the data context remain untouched even if new data came from the server. Xander, that is why you are seeing new data come over the network but this data is not shown in the UI.

    While this seems like a poor merge option, it's actually the safest we (as a general runtime) could implement initially. It matches the default that Entity Framework provides (see this link). However, for many scenarios, it isn't a great option, so we introduced a second merge option for VS 2013. This one, called "UnchangedOnly", has all the behavior of AppendOnly but also refreshes the data in entities previously loaded on the client if they are currently unchanged (we don't want to touch modified entities as that would affect the correctness of our concurrency checking). Collection refresh utilizes this merge option.

    The UnchangedOnly merge option matches the behavior we provided for the Silverlight client, and we believe it provides the most desirable behavior for the majority of cases. However, since we initially shipped with AppendOnly as the only merge option, we need to plan how to change the default without affecting existing applications. We are actively discussing how to handle these kinds of compatibility issues in a manner that doesn't stop us from making behavioral changes between versions. So, you can expect this to be addressed in the future.

    Hopefully this explains the behavior you are seeing, and why it is currently the expected behavior. My suggestion today would be to add a "Refresh" button to your tab that shows the list of order lines, so that the end user can manually refresh the results if he/she believes them to be out of date. I'm surprised actually that inserting a call to refresh the collection in the created or postRender events didn't solve the problem. That would be another approach that should work. If it doesn't, let's figure out what's going on there.


    Visual Studio LightSwitch Team

    • Proposed as answer by LightSwitch Team Friday, October 18, 2013 7:21 PM
    • Unproposed as answer by novascape Saturday, October 19, 2013 1:51 AM
    • Marked as answer by novascape Saturday, October 19, 2013 2:16 AM
    Friday, October 18, 2013 4:10 PM
  • Hi,

    I see the problem but why would you do that?

    Regards

    Sven


    Sven Elm

    Friday, October 18, 2013 4:53 PM
  • OK, changed reply as I had it wrong. I was calling .load() on the query instead of .refresh().

    So explicitly calling screen.MyQuery.refresh() does indeed refresh the display with the fresh data, so I will mark Stephen's answer as the correct answer and also do the same for Michael's initial answer as I should have figured it from that one.

    So by default the query is indeed using the "AppendOnly" behavior as suggested.

    The problem of course is that we cannot expect our users to click a [Refresh] button on every screen and every tab when they open it to be sure they have the latest data. Also, calling .refresh() automatically on the postRender() or elsewhere will result in two data trips (and double the data volume) to the server which again is not ideal.

    So looking forward to the "UnchangedOnly" merge option becoming the default in the HTML client.

    Anyway, I'm glad I got to the bottom of this one.

    • Edited by novascape Saturday, October 19, 2013 2:15 AM typo
    Saturday, October 19, 2013 1:49 AM
  • Change previous post above as I did indeed have it wrong so this post is just for notification purposes.

    Regards, Xander. My Blog

    Saturday, October 19, 2013 2:15 AM