Thank you all for the replies, in fact most of them scare me a bit because I'm using assigned GUID's and I see that you discourage this practice... I guess that all already persisted entities are previously loaded but I clearly identify from your replies that the tree entities construction in my application has some flaws.
BTW if I use generated GUID like with comb strategy after every insert NH will need to query again to retrieve this generated field and at the end I will need another select for each insert. Right? Regards, Guillem Solà On Mar 20, 2:28 pm, Ramon Smits <[email protected]> wrote: > You can use Session.Save(..) for the newly created objects. This way you > force NHibernate to do an INSERT. The problem is that sometimes this fails > because a root/parent objects does not yet exists in either the database or > set to the objects properties. In that case you should > > * take the lookup for granted as NHibernate does not know if it needs to > insert or update. > * don't use assigned identifiers > * remove the explicit relation between the child and the parent and don't > use treat it like an aggregate > > Regarding the 2nd, don't use assigned identifiers, I learned the hard way > that assigned identifiers should not be used as primary keys within the > database to share as it prevents optimized saving of aggregates in > nhibernate. This conflicts with modern principles that you want to generate > a key upfront to correlate different actions to. When you need such keys > then you should keep the primary key internal/protected so that it does not > have assigned identifiers but use for example hilo and have a guid property > as a 'natural' key.What I dislike about this is that you will always need > to join between the parent/child to fetch the child records. If that key > was part of the primary key then you could just do a simple select. > > Problem is that in most situations you would want to say to nhibernate > 'treat proxies as updates and non proxies as inserts'. That would prevent > such lookups. > > Hope this helps! > > On Tue, Mar 20, 2012 at 12:34 PM, Richard Brown > <[email protected]>wrote: > > > > > > > > > > > If you use assigned-identifier, and mix 'old'+'new' (i.e., > > persistent+transient) objects, NH cannot determine what has to be inserted > > and what is already there just by looking at the IDs. > > > You should load the existing persisted entities first. > > > var referenceEntity = > > session.Load<ReferenceType>(idThatIKnowExistsInTheDb); > > > The best solution is to not use assigned identifiers. > > > On 19 March 2012 21:26, guilemsola <[email protected]> wrote: > > >> Hi all, > > >> I have discovered that with nhibernate profiler with entities created > >> for the very first time... > > >> In my application I create a new entity that has a list of steps, and > >> each step a list of values. (I'm using inverses on mappings). Also > >> entities and steps references to master values already in db. So there > >> is a kind of mix of old and new objects. > > >> When I do the first Save I do Session.Save(entity) and the whole tree > >> is saved in database as it should be, but NH profiler warns about > >> that: > > >> Unable to determine if StepValueEntity with assigned identifier > >> ede6a5ee-b4bd-4f67-9c64-11ef85b7d6ff is transient or detached; > >> querying the database. Use explicit Save() or Update() in session to > >> prevent this. > > >> And effectively prior all the new entities insert there are a lot of > >> useless selects from NH because entities are not on DB. > > >> This is very inefficient, so what is the correct way to store those > >> new entities and tell NH that they are new? > > >> FYI this is how I do mapping for identity columns, maybe this doesn't > >> give a clue to nhibernate to know about what are new and already > >> persisted entities and I should do it in another way. > > >> Id(x => > >> x.Id).Column("GUID_PIPELINE_STEP_PARAMETER").GeneratedBy.Assigned(); > > >> Thanks in advance > > >> -- > >> 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. > > -- > Ramon -- 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.
