Load Only field is not serialized

I created a thread titled "How do I create a private set property on computed (load only) column?" and the question was answered with all the detail I asked for. Now I realize I was asking the wrong question.

My issue is really that I have a field marked Load Only that doesn't get deserialized at the client. From the previous post:

I have a computed column I want to load from a database entity (FullName = FirstName + ' ' + LastName) and
forward on to the client. I searched the archives and found several references to computed columns so I
made sure to set the field to Load Only = true. However, when I try to forward this entity to the client I
get a System.Runtime.Serialization.InvalidDataContractException saying there is no set property for that
field.

Following the User Guide and the confirmation I got from my last post, I set the field to FieldOnly and created my own custom property with a private setter and I can now deserialize the field at the client. However, when I try to save the entity to the database, Lightspeed also tries to save the field marked Load Only. See previous post for details.

I was a little dismayed when no one responded to my comments until I realized I was responding to myself and you may not have been notified there was a new post? At any rate, this is either a bug or a poorly documented feature and I am stuck as to how to proceed. If I provide a setter, private or otherwise, the field is successfully deserialized at the client -- but is also included when Lightspeed saves the entity to the database. If I don't provide a setter it doesn't get deserialized.

Please help! This can't be a new situation for you guys, is it?

Thanks, Dave

Hi Dave,

Is the field marked as readonly? Im guessing it may not not if you have defined a setter for the property. The field must be marked as readonly to avoid persistence and be treated as Load Only as that is our indicator that it shouldn't be written.

Jeremy

The field is marked Load Only = true in the designer, but all that does (that I can see) is generate a property with no setter. If I do that the deserializer doesn't work.

If I mark it as Generation = FieldOnly there is no property generated, as expected. That creates 2 problems and doesn't solve any: - If I create a property with no setter I am in the same boat I was in before. The deserializer fails. - If I add a setter to the property Lightspeed tries to persist the field, and that fails.

Where and how do I mark it so Lightspeed does not persist the field yet there is a setter in the property so the deserializer knows what to do with it? Do I need to use a certain variety of deserializer to make this work?

It seems to me I have to have to have it both ways... :)

Thanks, Dave

Setting Load Only = true should result in the field being generated as readonly, and any generated property would indeed be without a setter.

In terms of serialization, what is your scenario here? Are you trying to remote entities between a client/server or are you just publishing the entities as a resource (e.g. as JSON for general consumption) and is it single directional or bi-directional? Its not going to work to leverage the same underlying class definition for de-serialization since you dont have a setter - have you looked at using a DTO instead for this?

Jeremy

Hi Jeremy -

Thanks for answering my questions. I was never sure how to describe what I am doing but remoting entities between client and server describes it well. I ship entities back and forth between client and server. I also create entities on the client to be saved on the server (I still create a new one and copy values into it on the server side). To do this I need to reference the appropriate Mindscape Lightspeed libraries as well as the model library in the client app, but it has worked well for me up to this point.

I see what you are saying, but it never occurred to me to mix and match DTO and non-DTO entities in the same application. I will try to implement this and report back with my results. It has been a couple years since I looked at DTOs.

Thanks! Dave

This proved to be way more work than it was worth. Using a Transient field instead...