A good part of the frustration being experienced on both sides of this discussion is that there appears to be a disjoint about what NHibernate is: NHibernate is an ORM that enables ignorance of the persistence layer.
You want to use NHibernate functionality to manipulate values in your Database. What NHibernate really does is manage the values in the Object layer and at some point NHibernate persists logically correct data, in terms of the relational model, back to the Database. If NHibernate cannot translate the object data in correct relational model data an error occurs. You can simplify the relational model rules so that the object model will most always be able to correctly perform the translation, but these simplifications are always at the expense of referential integrity. If you do not need referential integrity in your DB then NHibernate can save the data in the way you want without loading the entity-graph, and the save will pass because there is no check in the database for the TicketID's existence. This means that both sides of a collection definition must be inverse=true (I have never tested to see if this is possible) and cascade is not possible (cascade needs the entity-graph to function). When I start a project I always start by setting up a Test Project that goes beyond normal unit testing and includes all read and write scenarios exercising the database so that the database contents are rebuilt for every test scenario. This allows me to validate all assumptions and shorten the UI development phase. Money is rarely an incentive in OSS projects. The way to get answers to the tough questions to make sure that you provide answers to others when you can, so that more experienced community members do not feel compelled to answer, a fact which they appreciate and then reciprocate when the answer requires a higher degree of expertise. I have been work on various OSS for almost 15 years and this is how it really works. John Davidson On Wed, Feb 9, 2011 at 12:26 PM, Joe Brockhaus <[email protected]> wrote: > i'm well-aware of how to make my entity graph's object references > completely solvent. > > my question is whether or not it's always required. > > can i have my domain mapped as i have it above (with cascade, etc) > > ... so that I can do: #1 > > // this simulates the use-case where the user is creating a new ticket with > x notes before saving > > var ticket = new Ticket(); > ticket.Notes.Add(new Note() { Ticket = ticket, TicketID = ticket.TicketID > }; // ad nauseam > Session.Save(ticket); > > > ... but also so that I can do: #2 > > // this simulates a use-case where the user is only adding a new ticket. > > var newNote = new Note() { TicketID = 1234 } // basically, everything that > the database row needs to be inserted. > // when I do the following .. i get either a cannot insert null error > (TicketID is not null in db) or FK not valid > // NHib would either try to insert null, or 0 (int default?), presumably > because the Ticket instance was null? > > Session.Save(newNote); > > > .. and also ... #3 > > // this simulates a user editing a ticket that has notes, but does not make > a change to the notes before saving > var ticket = this.TicketInstanceUserEditedAndSentToServer; > // the ticket comes back alone, meaning no Note instances are in its Notes > collection. > // which means when I do the following, NHib tries to delete the > children/null the FK in the table > Session.Update(ticket); > > > Is that a more clear description of how this is all happening, and why I'm > asking what I'm asking? > Can you see why it seems like a lot of overhead to re-populate the full > entity-graph in cases 2 & 3? > > ------------------------------------------------ > > > LOL. you don't get OSS do you :) not to mention the talent/value of the > people assisting you. > sure I do. money is money. free is free. somewhere in the middle are > reasonable grounds for tips, if you'd rather see it that way. as for > talent/value -- in this specific example, regardless of how super-awesome > someone thought they were in helping me, i'd still be the customer. I was > told to go away, and yet I'm still offering cash to those who help. I don't > think it's very polite on behalf of the rest of the community to say they > don't want it. ;-) > > and if the community doesn't want it, I won't have a problem leaving it in > my wallet ;-) but then i won't be surprised when i finally look that gift > horse in the mouth, either. > > you were in the running, but then you deferred to prior unhelpful remarks > of others so i felt less compelled. > pffsh, and you don't even want it ;-) > > ------ > Joe Brockhaus > [email protected] > ------------ > > > On Wed, Feb 9, 2011 at 11:39 AM, Jason Meckley <[email protected]>wrote: > >> when you associate a parent to a child the association goes both ways. I >> like to encapsulate my collections, so the only way to add to add a child is >> by the parent. it looks like this >> >> class Parent >> { >> private ICollectio<Child> children = new List<Child>(); >> >> public IEnumerable<Child> {get{return children;}} >> >> public void AddChild(string name) >> { >> children.Add(new Child(this){Name= name}); >> } >> } >> >> this allows my code to look like this >> session.Get<Parent>(id).AddChild("jason"); >> NH will automatically save the changes when the session is flushed. and I >> have 1 location in which to manage adding children to the parent. >> >> >> > I was going to offer $10 to whomever decided to actually help. >> LOL. you don't get OSS do you :) not to mention the talent/value of the >> people assisting you. >> >> -- >> 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. >> > > -- > 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. > -- 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.
