locked
What is the intention of the rowVersion field?

    Question

  • There is now a rowVersion field.

    I suspect it has to do with a different way Concurrency management is done ?


    paul van bladel

    Saturday, June 02, 2012 10:32 AM

Answers

  • The following article of John Rivard anticipated already on the rowVersion field

    http://blogs.msdn.com/b/lightswitch/archive/2012/03/22/lightswitch-architecture-odata.aspx

    "Another optimization we made is to include a RowVersion property for LightSwitch entities. OData uses ETags to handle data concurrency. These ETags can get large if they include original values from all of the entity properties—sometimes too large to fit in the request headers. By using RowVersion, we shrink the ETag to just one property value, while maintaining full support for concurrency checking and resolution. The introduction of a RowVersion also makes concurrency more robust because all properties are considered whereas in the past we excluded potentially large values like text, binary, and images. (Note: The RowVersion feature isn't yet available in the beta.)"


    paul van bladel

    Monday, June 04, 2012 11:34 AM
  • I'm glad you found John's blog posting.  Basically, the best way to get good database concurrency is to use rowversion, so now we put one on intrinsic tables for you, and we use it if your attached tables have it.  We had some concurrency edges cases in V1 we shipped with, and some of them got worse when we initially switched to OData.  We discussed a number of options to try and make the concurrency handling work better and ultimately we felt that the right goal was to push users towards using rowversion, as this is precisely the sort of job it was designed for. 

    You'll note that the rowversion column shows up in the list of properties in the screen designer, but we don't add it to your screen, so it won't be a concern for the users of your apps.

    I agree that it is a bit awkward that it shows up in some situations and not others.  The good news is that it won't show up in the UIs in the LightSwitch apps you create for your customers, and we felt that giving you (and your users) the rowversion technology was worth doing even if there was some wierdness in the LightSwitch developer experience.

    Monday, June 04, 2012 8:12 PM

All replies

  • Hello Paul,

    You mean the datatype "Rowversion"? In SQL Server it exists since a long time, it was first named "timestamp", but that name was confusing, because it's not related to a data/time.

    Yes, indeed, one intention is to handle concurrency. You can see, if a record was changed, since a client loaded it to edit data on his own. Other scenario is to use it to sync data; to can fetch all changed data since the last data sync was done. E.g. MS Sync Framework uses this datataype, if you want to create an app holding a local copy/cache of the data.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing

    Saturday, June 02, 2012 11:55 AM
  • Hi Olaf,

    Thanks for the update. Any idea why it has been added right now and not earlier?


    paul van bladel


    Saturday, June 02, 2012 12:52 PM
  • In LightSwitch? No, I don't know why and why now with this release.

    In SQL Server it exists since ... ever: http://msdn.microsoft.com/en-us/library/ms182776(v=sql.105).aspx


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing

    Saturday, June 02, 2012 12:57 PM
  • Hello Paul,

    You mean the datatype "Rowversion"?

    Hi Olaf, 

    Rowversion is in lightswitch not really present as a Data type. The type of the field Rowversion is a byte array.

    The field is by default present in the viewmodel in the screen designer. Since it has a pure technical nature, I don't see the reason why it's there. IN the entity designer it's not present.

    take care

    paul.



    paul van bladel

    Saturday, June 02, 2012 7:08 PM
  • I don't see it anywhere.  I must be looking in wrong spot.
    Sunday, June 03, 2012 1:44 AM

  • paul van bladel

    Sunday, June 03, 2012 5:59 AM

  • paul van bladel

    Sunday, June 03, 2012 5:59 AM
  • Rowversion is in lightswitch not really present as a Data type. The type of the field Rowversion is a byte array.

    Yes, it's a 8 byte value and auto incremented with every data change.

    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing

    Sunday, June 03, 2012 7:08 AM
  • The following article of John Rivard anticipated already on the rowVersion field

    http://blogs.msdn.com/b/lightswitch/archive/2012/03/22/lightswitch-architecture-odata.aspx

    "Another optimization we made is to include a RowVersion property for LightSwitch entities. OData uses ETags to handle data concurrency. These ETags can get large if they include original values from all of the entity properties—sometimes too large to fit in the request headers. By using RowVersion, we shrink the ETag to just one property value, while maintaining full support for concurrency checking and resolution. The introduction of a RowVersion also makes concurrency more robust because all properties are considered whereas in the past we excluded potentially large values like text, binary, and images. (Note: The RowVersion feature isn't yet available in the beta.)"


    paul van bladel

    Monday, June 04, 2012 11:34 AM
  • I agree with Paul that this is quite unexpected.

    The field RowVersion is now visible if you create a new screen based on an entity.  However, the UI never shows a value.  This is quite confusing.

    Suggestion => hide the RowVersion completely from the entity & screen designer.  Feel free to include it in the DB & OData endpoints.

    Keep rocking LS!

    Jan


    It's your story - time to switch on the innovation. || About me || LightSwitch blog

    Monday, June 04, 2012 3:57 PM
  • I'm glad you found John's blog posting.  Basically, the best way to get good database concurrency is to use rowversion, so now we put one on intrinsic tables for you, and we use it if your attached tables have it.  We had some concurrency edges cases in V1 we shipped with, and some of them got worse when we initially switched to OData.  We discussed a number of options to try and make the concurrency handling work better and ultimately we felt that the right goal was to push users towards using rowversion, as this is precisely the sort of job it was designed for. 

    You'll note that the rowversion column shows up in the list of properties in the screen designer, but we don't add it to your screen, so it won't be a concern for the users of your apps.

    I agree that it is a bit awkward that it shows up in some situations and not others.  The good news is that it won't show up in the UIs in the LightSwitch apps you create for your customers, and we felt that giving you (and your users) the rowversion technology was worth doing even if there was some wierdness in the LightSwitch developer experience.

    Monday, June 04, 2012 8:12 PM
  • Thanks for the update Matt.

    paul van bladel

    Tuesday, June 05, 2012 5:51 AM
  • Jan,

    Regarding hiding the RowVersion completely from the screen designer - what difference do you see with the Id property on the entity?  This property is visible when you create a new screen based on an entity, but the UI never shows a value.  Is that confusing as well?  Or have you just gotten used to having a hidden Id property, and now that there is a new hidden property it sticks out like a sore thumb?

    There are some reasons for having the RowVersion property visible in the designers, especially the query designer.  You can create a query that detects whether a record has changed or not.  The query would take 2 parameters: Id and RowVersion.  From the client, you can execute the query with an entity's Id and the current value for the RowVersion.  If a value comes back, then the record hasn't changed.  If no value comes back, then the RowVersion must have been updated, which means the record has been updated.

    Granted, there isn't a very compelling case for why you would ever want to display the RowVersion value on a screen.  But we felt that since the property does exist on the table/entity, we shouldn't hide it just because we can't think of a reason someone would want to display it.  I personally don't see an issue with having the property show up in the screen designer.  It doesn't affect the app's UI and if you don't interact with it, then it won't affect you, just like the Id property.

    Eric


    http://blogs.msdn.com/b/eric_erhardt/

    Tuesday, June 05, 2012 2:20 PM
    Moderator