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
|
Hello,
I have the following problem. For example, I have an Entity1, which has a lot of fields and properties, and I don't want to reload this entity from the database each time. Entity1 has a collection EntityCollection<Entity2>.
So, I load the Entity1 with its collection. Then, some data in this collection is changed outside the Entity1. After that, I want to load EntityCollection<Entity2> with new data and update the respective property of the Entity1.
Here is the example:
public void Test()
{
Entity1 e;
using (var uow = _context.CreateUnitOfWork())
{
// loading of Entity1 with its property EntityCollection<Entity2>.
e = uow.Entity1s.WithAggregate("AAA").First();
}
// here some data in Entity2 is changed
using (var uow = _context.CreateUnitOfWork())
{
// loading of EntityCollection<Entity2> with new data
var collection = uow.Entity2s.Where(ee => ee.Entity1Id == e.Id).ToList();
// and I want to update e.Entity2s with the values from
// collection without reloading of the full Entity1 to the database
}
}
How can I do this? May be, in this case I can use IsLazy property somehow? Thank you!
|
|
|
I think you would need to copy the new collection contents into the old collection. This would probably require some nasty Detach/Attach logic to ensure that the UOWs didn't get mixed up. But we'd discourage this because it means you can end up with an inconsistent view of your Entity1 -- the Entity1 would be in its original condition but it would have the collection data associated with a later state. If all you want to do is avoid the cost of reloading Entity1's core fields from the database while still getting a fresh copy of its Entity2s, consider using the L2 cache. E.g. // Assumes Entity1 is cached and Entity2 is not This keeps each object graph in its own unit of work, while avoiding the Entity1 database request. For info about caching see: http://www.mindscapehq.com/documentation/lightspeed/Performance-and-Tuning/Caching |
|
|
Hi, Ivan! What about EntityCollection`s IsLazy property? It`s got a public setter, so it seems like I can set IsLazy to false, then touch the collection and UOW goes to the database for actual collection. But it doesn`t work. Is it a bug? If not, why IsLazy have a public setter? Thanks!
|
|
|
I think the public setter for IsLazy is a design wart from the LightSpeed 1.0 days. It is mainly there to satisfy an internal interface contract. It should probably have been a method like SetLoaded() because the transition from unloaded to loaded is one-way, and it should probably have been internal. In any case, setting IsLazy=true does not unload the collection, and even if it did, the existing entities would remain in the identity map, so when you reloaded them, LightSpeed would see that entities with those IDs were already present and wire up the existing entities rather than creating new ones. |
|