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've been using Lightspeed for the last month or so in a relatively straightforward data access winforms application. Back when I first started, the statement... "A LightSpeed unit of work is designed to be short-lived."
found in the "Unit of Work Mechanics" section of the User Reference documentation lead me to come up with the following pattern to avoid keeping a Unit of Work around for the duration of the app. 1. User searches for records
2. User selects a record to view/edit
3. User edits record and saves record
I was hoping you guys could provide some best practice guidance for a typical Windows Forms scenario. Any possibility? Cheers, Greg |
|
|
Hi Greg, You're taking the correct approach. A couple of things: - You don't need to explicitly call BeginUnitOfWork - this API is for creating a nested unit of work which is a more advanced usage. - You can just call CompleteUnitOfWork() no parameters instead of passing true. I'm going to have a look at putting a WinForms sample together. I'll let you know when it's available in a nightly. Cheers, Andrew. |
|
|
Hi Andrew, - Is there any harm in explicitly calling BeginUnitOfWork()? If I've been deligent with completing the UOWs when they're used there should never be any nested UOWs. Correct? - Is it correct to call CompleteUnitOfWork(false) when I want to guarantee there are no updates going back to the db (for example after executing a search)? Or should this generally be avoided? Following on from item 2 above, I have run into an issue where a previous version of an entity is returned rather than the most current version - off the top of my head the general steps to reproduce are...
I will probably look to refactor my code to match your suggestions, but out of curiosity does the above code produce a result you would expect (ie: the state of the entity changes after completing the unit of work)? Cheers, Greg |
|
|
[quote user="gwhite"]- Is there any harm in explicitly calling BeginUnitOfWork()? If I've been deligent with completing the UOWs when they're used there should never be any nested UOWs. Correct?[/quote] Not really. [quote user="gwhite"]- Is it correct to call CompleteUnitOfWork(false) when I want to guarantee there are no updates going back to the db (for example after executing a search)? Or should this generally be avoided?[/quote] This is fine. Either that or don't modify any objects :-) I'll take a look at your update issue. Cheers, Andrew.
|
|
|
Hi again Andrew, I've been working on a repro for the issue I'm seeing when retrieving data after an update and I think I've got something that is fairly consistent. What's the best way to get the repro to you (I can't quite figure out how to upload to this forum!!!) Cheers, Greg |
|
|
Hi Greg, The best way to supply a repro is to either attach to a post (on the options tab you should see the option to attach a file? Let me know if you can't) or you can email it to us at contact@mindscape.co.nz. Also, have you tried using the latest nightly build of LightSpeed? We are rapidly approaching our 1.2 release and it includes several bug fixes. You can get the latest nightly here: http://www.mindscape.co.nz/Products/LightSpeed/nightlybuilds.aspx I hope that helps, John-Daniel |
|
|
Hi JD, Nope - no attach option - just smilies and reply restriction/notification options. Ah yes, I'll try my repro with the latest build prior to forwarding on. Cheers, Greg |
|
|
Hmmm, next problem. I just tried sending the repro to contact@mindscape.co.nz but got a NDR from google stating the attachement (.zip containing source - no binaries) was illegal. Any other ideas for getting the repro to you? Cheers, Greg |
|
|
Hi Greg, Can you please try looking on the options tab again? I've changed the permissions for the forum. Failing that, if you use MSN you could add me (traskjd@hotmail.com) and we could transfer your file that way. Thanks, John-Daniel |
|
|
Hi JD, Ok attachments look to be working now. See attached for repro. Thanks again, Greg |
|
|
Hi Greg, Thanks for the excellent repro. You're having a problem because in DataBind() CompleteUnitOfWork is called before you bind the child collections (ContractSummaries etc.) LightSpeed, by default, lazily loads associated collections and so these are being loaded in a new auto-created Unit of Work after the original one has been disposed. Then, when you call BeginUnitOfWork a new nested Unit of Work is created. So, to fix: 1) Remove calls to BeginUnitOfWork Additionally, set up a LightSpeed logger through LightSpeedContext.Logger as this is invaluable for observing LightSpeed's db interactions. Cheers, Andrew. |
|
|
Hi Andrew, Thanks for the explaination - so when the associated collection is accessed (ie: bound to) after the UnitOfWork has been completed, is Lightspeed creating a new UnitOfWork and then querying to populate the collection? I can imagine situations (especially in Winforms) where a user action causes the first access of an associated entity outside of the original data retrieval context. Any suggestions on appropriate strategies for dealing with these types of scenarios? Anyway, I feel a refactoring session coming on :) Cheers, Greg |
|
|
[quote user="gwhite"]so when the associated collection is accessed (ie: bound to) after the UnitOfWork has been completed, is Lightspeed creating a new UnitOfWork and then querying to populate the collection?[/quote] [quote user="gwhite"]Any suggestions on appropriate strategies for dealing with these types of scenarios?[/quote] - Use eager loading to pull back more data in one call. (EagerLoad attribute and Named Aggregates). Cheers, Andrew.
|
|