locked
LightSwitch with RIA service TimeStamp fields RRS feed

  • Question

  • I have a RIA Service in a separate class library which I use against a Silverlight application. All works great!

    I am trying to get the RIA service to work with LightSwitch and I have run into a little issue with TimeStamp fields.

    In silverlight I simple use the OnCreated partial method on the Silverlight application to prime the RowVersion = new byte[] { 0 }; RowVersion is the timestamp property in my case.

    In Lightswitch, the client code that is generated makes the RowVersion property ReadOnly and so it cannot be set using the provided [EntityName]_Created partial method.

    The issue with this is that I am not able to save the entity because the validation blocks the save operation.

    Does anyone know how to solve this?

    Thanks.

    Monday, August 8, 2011 7:21 PM

All replies

  • Can you update the RowVersion inside the domain service (ie. inside the RIA class library)? That way LS will just read and recognize the value after en entity is updated/inserted via your domain service.

    Regards


    Xander
    Monday, August 8, 2011 8:56 PM
  • From the RIA class library, the silverlight app or MVC there are no issues. This issue is specific to LS.

    In the Common project of the LS application there are some generated artifacts. The RowVersion column (with is a timestamp in the database used for concurrency checking) is readOnly. In the other generated files under the ClientGanerated project they are not.

    However, for the UserCode, which affects validation, the property is ReadOnly so I cannot prime the value to "trick" validation into accepting the value.

    I hope this makes sense.

    Regards

    Darrel

    Monday, August 8, 2011 9:38 PM
  • I use the same mechanism in mine and it has not caused any issues for me, but I notice that it is NOT a read-only property in my LS app. So it might be an idea to ascertain why it is read-only in your LS entities. I do the following:

    - I use EF entities within my domain service, which are exposed as presentation objects via the domain service methods to LS

    - Looking at my EF, Presentation Model and LS entity code, the RecordVersion properties are declared as follows in the different layers:

    EF Entity:
    [EdmScalarPropertyAttribute(EntityKeyProperty=false, IsNullable=false)]
    [DataMemberAttribute()]
    public global::System.Byte[] RecordVersion
    // Contains both get and set and Concurrency Mode is set to Fixed in EDMX

    Model object:
    [ConcurrencyCheck]
    public byte[] RecordVersion { get; set; }

    LS entity:
    [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.LightSwitch.BuildTasks.CodeGen", "10.0.0.0")]
    [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
    public byte[] RecordVersion
    // contains get and set

    I set the the RecordVersion property on the presentation model object from the EF entity on load and update it again inside the domain service methods after inserting or updating from LS.


    Xander

    Monday, August 8, 2011 10:42 PM
  • I don't have a model object which I expose. So this is might were the issue could be.

    However, I don't want to duplicate my entire database with separate models as this will result in quite a bit of work.

    Do you think this is a limitation with LS?

     

     

     

     

     

    Tuesday, August 9, 2011 6:20 AM
  • So you are exposing EF entities directly via your domain service? I've not tried that yet unfortunately...

    Even if you are saying that it works correctly for Silverlight and MVC, I still don't understand why you would have to manually to prime it? This is the bit that sounds "wrong/suspect" to me, although I will not classify myself as an EF expert per se.

    Surely the database (and consequently the EF) should prime this on your behalf after either inserting or updating entities? I would expect that property to be null when creating a new entity until it is inserted. Each time you call the EF to update an existing entity to the database it should automatically be updated to a new value for you.

    If you got it all working this far you might be close to a solution, so not sure that this is a LS limitation as such, without further investigation.

    Btw, my reason for using the presentation model object pattern is that it provides me with a lot of power and flexibility from within LS. An example is where I wrap the Link entity and Child entity of a many-to-may relationship into a single presentation model entity to make it easy to work with from a LS perspective. Another example is where I add additional action-type properties to the presentation model which can be read an acted on by the domain service to perform special server-side business logic. I also create "digest" objects to populate grids for example to lessen the client server traffic. It is more work, but it is worth it in the end I believe.

    Regards


    Xander


    Tuesday, August 9, 2011 11:12 AM
  • Xander

    Thanks for your time on this.

    My issue is that it is creating the entity on the client and not retrieving it from the server. As you know the default value for a byte[] is null. Which means that the validation on the client side, in this case LS, is triggered and stops the save from posting back to the server.

    In the silverlight application I am able to prime the RowVersion when creating a new object on the client. There is no validation error becuase it contains a value. Once the data gets back to the server, all is well ... the entity is updated to the database, a new timestamp is created and sent back to the client.

    This is only a problem in LS when creating an entity on the client that has a timestamp field. Some of my tables do not have timestamp fields and they work fine.

    I think, it is just a problem with the code gen, but I might be wrong.

    Regards

    Darrel

    Tuesday, August 9, 2011 11:28 AM
  • So you are exposing EF entities directly via your domain service? I've not tried that yet unfortunately...

    Even if you are saying that it works correctly for Silverlight and MVC, I still don't understand why you would have to manually to prime it? This is the bit that sounds "wrong/suspect" to me, although I will not classify myself as an EF expert per se.

    Surely the database (and consequently the EF) should prime this on your behalf after either inserting or updating entities? I would expect that property to be null when creating a new entity until it is inserted. Each time you call the EF to update an existing entity to the database it should automatically be updated to a new value for you.


    Xander



    This is my feeling also.

    However, in my experience I am exposing LightSwitch Entities in my WCF RIA Service (and LightSwitch is consuming the service. I am doing this because it allows me to perform complex queries and operations that would be brittle and convoluted otherwise).

    So, if these are not LightSwitch Entities, that could be difference?


    Make Them Ask: That's a LightSwitch App?

    http://LightSwitchHelpWebsite.com



    Saturday, August 13, 2011 7:49 PM
  • Is there a way that someone from the LightSwitch team could answer this?
    Sunday, August 14, 2011 5:35 PM