Hi Renso.Please try to buy NHibernate in Action book. 2008/12/8 Renso <[EMAIL PROTECTED]>
> > Hi Fabio, to answer your question and to clarify my answer: > > I don't understand what you are talking about. If the ID have no meaning > why > > your user must see it ? > > If you need to know which element is selected you may use the index of > the > > list, if you are using ISet you should implement an EqualityComparer. > > If the user sorts the list client side, like a list of addresses, the > order is not known by the server side code and thus the id is required > in the list so that when a user changes a specific address in a list > and the save button is hit on that row on the client the server may > know what address had been changed (remember duplicate addresses are > allowed implicitly as their is no way to determine if two addresses > are the same based on the nature of how users type in addresses and > abbreviate words like Street as opposed to ST or Str. etc). I agree > the user may not need to see the id but it needs to be there, possibly > as a hidden control. In the example of a TrafficLine as in my example > before, it contains a start date and amount, which both can be the > same, so there is no way to use EqualityComparer. That is why I have > an IList. > > So if I understand you correctly: SaveOrUpdate is basically used to > defer the actual DB save/update as late as possible so that all newly > added children records will be persisted on flush (which in turn > commits the transaction). This I agree is a great strategy, especially > if you want to make further changes to those new children records > before flushing the session, for example after I instantiate some new > traffic line objects I want to make changes to each of the new traffic > lines base on the total of all new traffic lines just associated to > the parent. All I am trying to say here is that I may want to make > some changes to the new objects before I persist them to the DB. If I > had called SAVE on each traffic line, I would end up with a bunch of > inserts and updates hitting the DB. So if I use the SaveOrUpdate on > the parent with cascading set to save-update, the newly added traffic > lines (chidren) will only hit the DB once for each. Good performance > benefit. However, the ids will not be returned for the children, ONLY > an INSERT is generated! But on the other hand, if my list of traffic > lines cannot be unique identified by Equality because they may be > "duplicate", and the client-side code can order them in a different > order than what the server is aware of, I (the server-side code) will > need their ids to identify them, so in this case I am going to use > SAVE for each traffic line (child), get its id, so that when the list > is built in my MVC page, before the session is flushed, I now have the > ids that I will need when the user updates a specific child in the > list on the client and an ajax request is sent using the id to > uniquely identify the record/row (traffic line) when it is updated. > Another thing to also mention, is that if the traffic line is changed > on the client side, even if I was able to uniquely identify it via > EqualityComparer, the server side code would not be able to know what > record you updated because it has been changed. I am not sure if I > have explained myself properly, just let me know. > > Thanks again Fabio for your advice. > > Renso. > > On Dec 8, 9:27 am, "Fabio Maulo" <[EMAIL PROTECTED]> wrote: > > 2008/12/8 Renso <[EMAIL PROTECTED]> > > > > > > > > > Fabio, thank you very much for your reply. > > > > > 1. Do you know why it does return the id when you perform a SAVE > > > directly on the child (_traffcLineDao.Save(newTrafficLine);)? > > > > Yes. you are explicit persisting an entity avoiding automatic cascade. > > > > > 2. Why does it work differently than the SaveOrUpdate on the parent? > > > > Because the parent is a RootEntity and the ID are needed before > > save children. > > > > > > > > > 3. Is there a post somewhere that explains this i depth that you know > > > of? > > > > May be documentation or, in alternative, this post. > > > > > I would imagine that it should be very common to retrieve the ids > > > right away after an object is persisted (i.e. before the session is > > > finally flushed), like when lists are returned, so that when a user > > > clicks on a specific listed item it will have the id already in it so > > > that the server knows which child was selected. This is especially > > > true when you look at the suggestions from the NHibernate docs where > > > ids are recommended rather than natural keys, as in many cases like > > > list of addresses, etc, it is not possible to identify a unique > > > address by its content/natural keys (for example 100 Main Street is > > > the same as Main Street No 100). > > > > I don't understand what you are talking about. If the ID have no meaning > why > > your user must see it ? > > If you need to know which element is selected you may use the index of > the > > list, if you are using ISet you should implement an EqualityComparer. > > > > > > > > > 4. I would like to understand how the different persistence options > > > work, pros and cons so I can make an informed decision on which one to > > > use. > > > > Probably in some course. > > > > -- > > Fabio Maulo > > > -- Fabio Maulo --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
