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, Thanks for your previous help btw - but another query sorry! : ) We use Lightspeed in our appointment book module. The appointment book module is an add-on to a seperate application (our main program) so we are in the situation where both our main application, and the appointment book module can write to the database to make changes. We are experiencing what seems to be caching issues where Lightspeed is performing the Select query from the database but the collection it returns does not contain the updated data for some reason (ie it brings back the same collection of data that it had previously even though we have changed some of that appointment data through our main application.) If we close and restart the appointment book the correct data is returned. We haven't set any caching properties on our main appointment entities so any ideas why the latest data is not getting selected? Thanks for your help. |
|
|
It sounds like the entities are already in the unit of work. If LightSpeed issues a SELECT, and the returned row has already been mapped to an entity in this unit of work, then LightSpeed will use the existing entity rather than creating a new one from the latest returned data. To ensure fresh data, use short-running units of work. |
|
|
Hi and thanks for the snappy reply. You were correct about us using a long life UOW. We use one uow with two data repositories. One loads the full resource collection and the other loads a range of appointments. The appointment control needs to match the resource objects to the corresponding appointment.resoruce[] objects. If we renew the uow for the appointment repository then the link to the resource collection is broken because the resource objects no longer match. Things are slow enough without having to rebuild the resource collection every time we refresh the appointments. So is there another way to force the uow to load fresh data? |
|
|
No, there isn't. It's something we get asked about quite frequently, and it remains high on our list of features we'd like to implement, but there are significant issues to do with associations. (For example, what if you reload Resource A, and someone has modified Appointment C that used to point to Resource A so now it points to Resource B? The FK is on Appointment C, which we're not reloading, so we won't pick this up when reloading Resource A. We could invalidate Resource A's Appointments collection after reloading, but what if Appointment D has been modified in the UOW to point to Resource A? Do we orphan/delete Appointment D? Do we try to remember what resource it used to point to, and restore that? What if that resource has now been deleted? It's a can of worms.) If you're not able to reload regularly for performance reasons, you may need to consider alternative approaches. For example, rather than keeping a unit of work and its entities around for a long time, you might keep viewmodel objects, and load and unload entities only when you need to reload or persist. This would allow you to reload only the entities you need, and update only the viewmodel objects corresponding to the changed entities. Of course, the downside is that now you have viewmodel objects as well as entities, which can create a maintenance burden, especially if the model is large. You might be able to work around this by using entity classes as your viewmodel classes, but not having them in a UOW except when loading or saving (using Attach, Detach and Import, though this brings its own problems). You can probably think of better approaches since you know your own app and the relevant transaction boundaries, but the general principle of trying to make smaller, faster queries using short-lived units of work is the thing to aim for. And of course we'd be happy to advise on more specific ideas though we would need to know more about your app structure, entity lifecycle and transaction boundaries -- drop us an email if it is sensitive, though we prefer to discuss these things on the forums where they can help other people with similar problems! |
|
|
Oooooh. This could be a bit of a show-stopper for us and I wish we had found it a long time ago! Our main appointment select statement gets the appointments and all of it's required associations so I don't see why there can't be a method to clear the internal cache of this UOW's previous selection and just get the data back as it is in the database. Anyway... You said this was high on your list of features you want to implement. How high is it and when do you review such things? We just have to now make a decision as to what we do as we have an application nearly ready to go (meant to be demoing it on Friday) that has been designed with a long lived UOW that we now know gives us stale data. Cheers. |
|
|
Well, as for why, see my previous post in this thread -- the design issues with reloading an individual entity are subtle and complex, and a naive implementation would set many traps for its users. You can safely clear the "internal cache of the UOW's previous selection," of course, but that will incur a reload of everything from the database. If you really really need to update an individual entity from the database, one idea is to look at the Import method. Load the fresh data in a new unit of work, then import that fresh data into your long-running unit of work:
I haven't tested this for the scenario you describe, and you still face the issues that I described in my earlier post, but I think it should suffice if you are careful about how you handle entities with associations. Note that this will result in the entity in mainUow being marked as modified (because it has been modified relative to its original state), so you will get superfluous updates, but I'm guessing those are less of an issue than stale data. We do not have a proposed timescale for the 'reload individual entity from database' feature. It has been on the backlog for several versions now: it is high on the list of features we want to implement, but we have not yet been able to crack the design issues, so it tends to get deferred. It is certainly not something we are planning to implement immediately -- sorry! |
|