2008/11/2 Craig Neuwirt <[EMAIL PROTECTED]> > I could be wrong, but if I am an AR user and I just want to retrieve > data, I would create a session scope and do my retrieval. If I plan to > perform updates I would create a TransactionScope, do my updates and > commit. I was just suggesting we align the flush behavior with those > scenarios to avoid having to remember to pass any parameters to the > scopes. What scenarios would this break on? >
This works for most simple scenarios when I want a TransactionScope directly around the changing code. Complex situations don't have this explicit boundary. A rather simple example: DomainService ds wants to update some data: It creates a TransactionScope and calls an aggergate root's method to do the changes. The entity updates some of its internal entities. It now has to check the consequences and creates a few value objects to do compelx calculations. These calculations call the aggregate's repository to get aggregated data from DB. This situation can currently be handled only by adding if (SessionScope.Current != null) SessionScope.Current.Flush(); at the beginning of every repository method. That works with hand-rolled repositories, but don't ever try to use Rhino Commons or subclass ActiveRecordMediator and call MyRepo.FindAll(...). On the other hand, the scenario you describe above is still perfectly working with autoflushing. It's not that you can't roll back flushed data. We just talk about first level dirty checks. The second point is deterministic behaviour. Code is currently behaving differently based on whether it is called without a scope, within a SessionScope or within a TransactionScope. So if we remove autoflushing completely, we also had to disallow ad-hoc usage without any scope at all. -Markus --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
