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
|
I'm using Lightspeed with the Unit of Work pattern and Structuremap (HybridHttpOrThreadLocalScoped), and creating a user followed by:
All of this is inside a unit of work. The UnitOfWork appears to have the new entity in it, but the Query() method doesn't return the entity. I'm using SaveChanges() to get around this, but it seems to defeat the point of the Unit of Work pattern, if I have to flush everytime I save. Is there something I'm missing? |
|
|
If I am understanding your scenario correctly you are creating the User within a UnitOfWork and then trying to execute that query where the User you want to find has not yet been persisted? If so yes you would need to call SaveChanges in between this to have the user found. The reason for this is that unitOfWork.Query You can however query against the entities stored in the local identity map by using the UnitOfWork instance itself as a queryable source, so you could execute:
or if you want to check both sources
|
|
|
It'll make it a bit complicated checking both sources, so I'll stick with SaveChanges. So does Find work outside of the UnitofWork? Or it assumes you've flushed your unit of work first? I've setup up the unit of work to be per-HTTP request but presumably all that really means is it uses the same connection throughout (which I think NHibernate does too) |
|
|
Find operates over the database, so if you need a consistent view then you will need to flush any pending changes. Yes you are correct that if your UOW lifetime is for a single HTTP request then a database connection will be open from the time you first perform a query against the UnitOfWork through to when you dispose it (presumably you will be doing this at the end of the request).
|
|
|
Thanks Jeremy that's made it a lot clearer. Coming from NHibernate, it was always bit mysterious (except for the NH consultants/devs of course) knowing at what point it decides to flush to the database so this is a lot more obvious. It's also really nice to get to see the SQL statements streamed to log2console and have some meaningful error messages! |
|