Thanks Anne, I had already considered the version option but I discarded it as I considered too much to add an extra column in every table.
Finally I decided to use a guid comb generated that took me 10 minutes with fluent to change on mappings and now there are no more select prior inserts. Regards Guillem Solà On Mar 20, 8:08 pm, Anne Epstein <[email protected]> wrote: > Guillem, > You're going to have an easier time if you go with some of the other > responses you've already received, but if you don't want to change > your Id column yet adding a column is an option for you, an > alternative you can try is to use a version column. Doing so should > allow you to use an assigned id but avoid these sort of assigned-id > problems you've been facing, such as having to explicitly choose save > or update. Since I think you're using Fluent NH, that might look > like: > > Version(entity => entity.Version) > > I believe you could alternatively go with timestamp here, but haven't > done that personally. > > Hope that helps! > > > > > > > > On Tue, Mar 20, 2012 at 12:18 PM, guilemsola <[email protected]> wrote: > > Ok, I see it. > > > If I use a generator like guid comb NH doesn't need to do a select to > > know which ID has been assigned and it easily knows what is a new and > > an old object. > > > Thank you all for your help! > > > Guillem > > > On Mar 20, 4:54 pm, guilemsola <[email protected]> wrote: > >> 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 > > athttp://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.
