For future reference I would like to know how I could have handled this situation using NHibernate, so if you'll bear with me I'll give you a brief synopsis of what I am trying to achieve. This is a transportation/logistics application.
User creates or opens a job A job for these purposes contains 3 children a shipper, a customer, and a list of details. Each one of those details contain 2 children a consignee and a weight factor User will add multiple weight factors and multiple job details utilizing those different weight factors All of this is done in memory and no changes are persisted to the database until the save button is pressed. The reasons behind this are plenty, but the most weighing issue is that when a job is being created there are a huge number of changes made and when you consider that a single job could possibly contain close to a thousand points it is much more responsive to work with an in memory model rather than working directly with the DB. So I was trying to use NHibernates cache to do this rather than storing everything in data tables as I did before. I understand where the identity issue came into play; I actually dealt with the same issue when I was dealing with data tables directly. I got around this limitation by using an arbitrary non persisted property of these objects to indicate whether the identity is a valid identity or not by simply using a bool that is called IsNew. There were two things I was trying to achieve in this process with NHibernate that I could not due to my lack of knowledge I assume. First was the issue that my weight factors are unique, there are no duplicates in the db, however I don't get a list of weight factors the user manually types them in each time, searching through the list would be awfully cumbersome. So since everything is in memory I don't know if it is a duplicate until the save process occurs, this is actually done in a stored procedure, the sproc checks to see if it is a duplicate if it is it returns the identity of the duplicate otherwise it adds a new one and returns that identity. As far as I know NHibernate doesn't do this automagically so it would have to be done through coding this process but I found that I was getting an object null reference exception when it was trying to create a duplicate weight factor. That took me forever to find out because the exception reporting in no way indicated that was the issue. If I could have saved any time in the learning process of NHibernate it would have been if the exceptions were a bit more informative, but this could be because of an issue that is beyond my comprehension. Second is that I needed everything to be an in memory representation and when the acceptall or a save -> acceptall (for new jobs) was done it would just persist everything to the database allowing me to get rid of large chunks of code that parse data tables to get the information that it needs from them and persist changed and new information to the db. I was not able to achieve either of these issues. My only way I know to get around them is still to employ the use of data tables and parse them again during the save process and create the objects for NHibernate during this process. If that is the case NHibernate does not provide me an increase in development productivity and in fact with the use of IoC now, which was required for the session handling that I needed, it has slowed me down extensively because I am having to essentially redesign my app to use all of these new interfaces that I was not using before. I understand this would be greatly negated when I finally finish this conversion, but until then it has been a huge drain on my development time and debugging is much more complicated now since I am programming against interfaces so I have to set up a debug points all throughout the code rather than just being able to step through. When I decided to make the leap to using an ORM in my system I never felt I should have to change my application to work around an ORM that an ORM, by its nature that it is a tool (i.e. you wouldn't change how you built a house because you bought a new hammer), should be flexible and adaptive to my application. This has proven to be incorrect in the case of NHibernate, or at least in my use of it and the answers to the questions I have asked here seem to indicate that I am correct in my conclusion that NHibernate isn't as adaptive as I need it to be. Now I know that may anger some of the developers here, and please do not let it. I don't claim to be god's gift to programming and the way I do things may not be orthodox, but it has carried me in my career thus far. I think NHibernate is a great tool despite all of my troubles, and had I been working in a web app rather than a win forms app I would definitely use it. I do think there should be more thought into handling the types of issues that NHibernate has with Identity as there are a lot of developers out there that use it and transitioning an already existing database to guids would be a nightmare if it is of any size at all, and once again they shouldn't have to do that to utilize a tool, that tool should be adaptive. Also if at all possible more meaningful exceptions would be of great benefit and would lessen the learning curve dramatically, IMHO. Anyways, if any of you read to this far, thank you for your time and I REALLY look forward to responses. Thanks, Josh On Wed, Jul 1, 2009 at 11:34 PM, jobsamuel <[email protected]> wrote: > > I thought that since you are using db generated identity, your save > would result in a db call and your further call to criteria query > would work. Even if you are not using db generated id the session > would automatically flush upon a query and your criteria query should > still work. I think this is mentioned in the document that in flush > mode auto firing a query happens to be a flush point. > Is my understanding wrong, if it correct then your criteria query > should have worked, what is the reason for it to fail? > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
