Hi Jason, cheers, this all makes sense. about the detached/attached objects. The exception logic you've outlined makes sense too.
Back to the main topic though, One of our colleagues raised concerns that identity keys mean you can't use first level cache. I thought however that NH will hit the db early for updates, and updates are not cachable, so I'm wondering how first level cache is effected. My collegues explaination from email was: "As the first level cache within the session would have to save and flush new entities to the database and retrieve the newly created Ids before they could be associated with other objects. More of an issue when you’re dealing with saving and manipulating a larger graph of data." Does NH getting inserting the record 'early' to get the next ID flush the session and thus the 1st level cache? Is it not that case that NH gets the id it needs but does not flush the cache? On Nov 2, 2:02 pm, Jason Meckley <[email protected]> wrote: > if you retrieve and entity from NH it will track changes made to the > entity. If you edit a property/field. If you add/remove an object from a > collection. if you change a referenced entity. NH will know what you did > and update the database records accordingly (insert, update, delete). This > also depends on how you map the entities. But in general NH will handle > this for you. > > The one time you need to explicitly call session.save is when you are > adding a new transient object without reference to a persistent object. > in other words > var customer = new Customer{ name= "jason"}; > session.Save(customer); > > other than that, you typically don't need to explicitly call save, > saveorupdate or delete. > > "If we where to attempt a session.flush or session.commit in end_request > and indeed there was an error for sure we could rollback and maintain DB > integrity however how would be handle errors, would we not be limited to > just redirecting to a generic error page." > not true. you still have access to the entire request and can decide what > to do next should you encounter an exception. In other words handle the > exception based on exception type and the context of the request. > > typically the exceptions encountered at the point of committing changes > should be so negligible that the exception truly is exceptional and the > best choice of action is to inform the user with a generic error and to > "try again". > verification and validation would have already be preformed within the > service layers. these layers would provide the specific context of what to > do if the data is not correct. -- You received this message because you are subscribed to the Google Groups "nhusers" 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/nhusers?hl=en.
