This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, I recently upgraded to Lightspeed 5 and I am having an issue with the EntityState property. The entity is being put into the view state on our web pages and when it is pulled back out of the view state its EntityState property is always set to Default. All of the other properties appear to be de-serializing correctly. Is there any way to track down why this property is not being de-serialized with the rest of the properties? Thanks |
|
|
|
|
No, this property is specifically not serialized as it is used for entity tracking within a UnitOfWork scope. If you are bringing entities back into a new UnitOfWork you should either use UnitOfWork.Attach or UnitOfWork.Import to correct re-associate these and this will in turn update the EntityState property accordingly. Can you elaborate on what you are looking to do with round-tripping the entities via ViewState?
|
|
|
|
|
Jeremy, Was it not marked for serialization previously? I looked at the EntityState property for the Entity class in 5.0 and 3.11 and they both have the XmlIgnore attribute but neither have the NonSerialized attribute. I actually rolled back the dlls to 3.11 for a sanity check (because we also upgraded to vs2012 at the same time as upgrading to LightSpeed 5) and the property was persisted as previously. We could likely make this suggestion work...though I would like to avoid it if possible because there would be a ton of refactoring involved as we have relied on Entity.EntityState for a large number of features in our site. We keep the entities in ViewState to persist their state across postbacks. Thanks, Adam |
|
|
|
|
Yep its certainly possible that it was previously serialised but this is not intended behaviour Im afraid. Given what you are doing I would suggest using UnitOfWork.Import() to re-attach the associated entities to the UnitOfWork which will update the EntityState property in respect of the current database state.
|
|
|
|
|
Jeremy, Sorry for the delay in response, we had some other issues take precedence. Should import work for only the entity that is imported and not all of the child entities? Currently on import all child relationship entities are lost. If it is going to be required to import every single related entity we will have to change pretty much every view model in our system to import all of the entities it uses. Is there not another way to accomplish this without using the import? Adam |
|
|
|
|
UnitOfWork.Import only deals with a single entity and doesn't traverse associations, you need to handle this manually. There is an overload which allows you to supply a custom mapping function which you could use to manage this or you can manage this in your calling code. Its likely to be about the same either way though.
|
|
|
|
|
That is not going to be something we can support. Would be it be possible to have a property added that would allow the EntityState property to be serialized? We just upgraded our license and we are kind of at a standstill with actually upgrading our solution because of this issue. |
|
|
|
|
Hi Adam, Sorry but the serialisation is controlled by the attribute markup on those classes so we cannot provide a switch for this. Additionally we explicitly dont want EntityState being serializable as this can lead to inconsistency from us expecting this property to be managed within the scope of a UnitOfWork. One option here is if you have a source license you can compile your own version of the runtime with the [XmlIgnore] and [IgnoreDataMember] attributes removed from the EntityState property. This is not something I can recommend since there are likely issues which will stem from such a change which we cannot support but if you are happy to wear that risk then you can use this to handle the requirement you have.
|
|
|
|
|
Jeremy, Its been a while since I have been able to address this but I am taking another look and I have updated to the most recently nightly build available to us (8/20/2014) and I still am at a loss to what to do here. The import statement doesn't really give us what we need as alot of our code is highly re-usable and in order to correctly use the import suggestion we would need to override methods in pretty much every class in the part of our application that interacts with the lightspeed models and then create new unit tests for pretty much every single entity type in our system. We are a small team and that is not something we can do in any sort of reasonable time frame. I want to continue to use lightspeed (and renew again) because I have been very happy with it in general other than this issue. We have not been able to actually use the upgrade we purchased a year ago so I cannot justify renewing unless we can find some better resolution to this issue. I have also tried some other solutions, such as creating a key and storing the entities in server memory but that became unwieldy very quickly as the entity stores the unit of work context if it is not serialized which as I am sure you know can create an extremely large memory footprint. I honestly am at a loss because I don't understand how it works correctly in 3.11 if the EntityState property is not marked for serialization in that version. If the answer is to purchase the source code version of the product and alter the EntityState property there, we would need a to be able to attempt it before we made the purchase. Is there a way we can do this? Thanks, Adam |
|
|
|
|
Hi Adam, Can you email us at support at mindscape.co.nz and I can arrange for something here.
|
|
|
|
