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
|
My task is to perform unitOfWork.Detach(entity) for each entity loaded from a database. |
|
|
Could we get more information please? Why would you need to detach as soon as an entity is loaded? In LightSpeed 3.0 you will find the UnitOfWork now implements IEnumberable<Entity> so you could write code similar to: foreach(var entity in MyUnitOfWork) There are also life cycle hooks available on the entities themselves should want to hook those. I hope that helps, John-Daniel Trask |
|
|
I use LightSpeed only for loading data from a DB. For saving changes into DB I use stored procedures. Therefor i must reload updated by stored procedures data from DB each time when i ask unitOfWork for some data. See Stored Procedure and UnitOfWork entity cache and http://www.mindscape.co.nz/forums/Thread.aspx?PostID=7293 for details. Ivan has advised me dispose and recreate unitOfWork each time when i want force loading data from DB. But when i try to call property of entity loaded through disposed unitOfWork i get appropriate exeption. Detaching of each entity loaded from a DB can solve my problem. |
|
|
Hi, Thanks for the extra information - that makes sense. Hopefully the approach for mass-detach that I mentioned is working for you? Kind regards, John-Daniel Trask |
|
|
Yes, your approach is suitable for me, thank you. |
|
|
It would be great if you provide us with best practice of using LightSpeed in case when Lightspeed is used only for loading data from DB and saving data is performed by stored procedures. May be my method with disposing and recreation of UnitOfWork is not optimal. |
|
|
Best practice mentioned above is really needed. I have big scruples in optimality of my implementation of UnitOfWork management from perfomance and scalability points of view. |
|
|
Could you say a bit more about your use case and you would use these events to improve performance and scalability? Thanks! |
|
|
These events cannot improve performance and scalability. The question is other. My use case is described in a details in http://www.mindscape.co.nz/forums/Thread.aspx?PostID=7293. BeforLoadEntity and AfterLoadEntity events could be useful in my implementation of UnitOfWork managment. In that implementation i perform unitOfWork.Detach(entity) for each entity loaded from a database. Reason see above. JВ advised me use possibility of UnitOfWork to enumerate loaded entities ("UnitOfWork now implements IEnumberable<Entity>"), instead of these events. I suspect that these two methods may cause perfomance degradation when count of detaching entities will grow. At least, detaching of all loaded entities is not beatiful solution and is not best practice. |
|
|
May be a best solution for my use case is loading entities from a DB without attaching to unitOfWork. |
|