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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
