Neither is my View Model identical to my Domain Model, nor is the Domain Model simple.
So, if I understand your advices correctly, you are basically saying that IsDirty shouldn't be used to check if there are any changes in the domain entities, rather I should implement my own change tracking? Then I'll have to ask, what is the purpose of IsDirty? On 29 Okt., 00:17, John Davidson <jwdavid...@gmail.com> wrote: > NHibernate is meant to manage the Object-Relational interface between your > Domain Model and your persistence layer (RDBMS). > > It is not used to manage the ViewModel interface with the Domain Model. Any > functionality that seems to support this interface is incidental and as you > are finding will not work the way you are hoping. There are samples where > the ViewModel and the Domain Model are identical, and I wish these samples > had never been created, because they only work correctly because of the > simplicity of the Domain Model, and everything falls apart when a more > complex Domain Model and ViewModel are attempted. > > I would seriously recommend you rethink your architecture. NHibernate is not > a panacea for poor design. > > John Davidson > > On Thu, Oct 28, 2010 at 11:43 AM, cremor <cre...@gmx.net> wrote: > > I am using ViewModel objects for the binding to my screens. But my > > ViewModel objects must write the data to the domain (NHibernate) > > objects, how would I use the business logic otherwise? > > Also, if I only write the data to the domain objects on save, I'd have > > to implement change tracking myself. NHibernate already implements > > change tracking, so why not use it? > > > On 28 Okt., 17:28, John Davidson <jwdavid...@gmail.com> wrote: > > > This is the reason for using a DTO rather than the NHibernate object. The > > > DTO data is only moved to the NHibernate object after the user has > > pressed > > > save. Screen objects should not be NHibernate objects. > > > > John Davidson > > > > On Thu, Oct 28, 2010 at 9:31 AM, cremor <cre...@gmx.net> wrote: > > > > Just for curiosity I switched my ID generator from Sequence to > > > > SeqHiLo. Calling session.IsDirty() now doesn't execute a select > > > > statement for the ID anymore (which is expected with SeqHiLo), but it > > > > still queues the insert statement. > > > > Then I even implemented my own IIdentifierGenerator which just returns > > > > an increasing number in Generate(), and IsDirty() STILL queues the > > > > wrong insert statement! > > > > > What's the reason for this? > > > > > I highly doubt that this behaviour is as designed. Because, in > > > > addition to the problem with not null or check constraints and the > > > > inconsistent behaviour I explained in my first post, this even results > > > > in the following behaviour, that is clearly a bug in NHibernate in my > > > > opinion (please tell me if I'm wrong): > > > > > Use-case: > > > > 1. Persistent Parent is loaded. > > > > 2. A new Child is added to the collection. > > > > 3. session.IsDirty() is called (UI checks, if it should enable the > > > > save button). > > > > 4. NHibernate queues an insert statement for the Child using its > > > > current (default) values. > > > > 5. User deletes the just created Child again (it is removed from the > > > > collection in the Parent). > > > > 6. User saves the changes, session.Flush() is called. > > > > > Now NHibernate does the following: > > > > 1. The queued insert statement for the new Child is executed (let's > > > > ignore the not null constraint for now). > > > > 2. Parent version column is updated. > > > > 3. The child (which shouldn't be in the DB) is commited. The next load > > > > of the Parent will return the Child which shouldn't be there. > > > > > I'd really appreciate any advice on this topic - or a NHibernate > > > > bugfix ;-) > > > > > On 7 Okt., 15:49, John Davidson <jwdavid...@gmail.com> wrote: > > > > > You probably need to do an id check yourself first, before the > > IsDirty. > > > > > > John Davidson > > > > > > On Thu, Oct 7, 2010 at 7:32 AM, cremor <cre...@gmx.net> wrote: > > > > > > Sadly, a different ID generator is no option for me. My application > > is > > > > > > not the only one accessing the DB and the other systems rely on > > these > > > > > > sequences. > > > > > > > What is the reason for getting an ID and flushing the Child when > > > > > > checking IsDirty()? Shouldn't it be enough for NHibernate that the > > ID > > > > > > of the Child has an unsaved-value? > > > > > > > On 7 Okt., 12:56, John Davidson <jwdavid...@gmail.com> wrote: > > > > > > > The use of sequence is similar to identity in that the db > > generates > > > > the > > > > > > id > > > > > > > stored rather than the other id generators which create the id > > within > > > > > > > NHibernate. For your problem the issue identified in jira NH-2136 > > is > > > > the > > > > > > > same. > > > > > > > > The solution is to use an NHibernate created id from hi-lo or > > guid > > > > based > > > > > > > generators. > > > > > > > > John Davidson > > > > > > > > On Thu, Oct 7, 2010 at 4:09 AM, cremor <cre...@gmx.net> wrote: > > > > > > > > I currently have the problem that NHibernate creates an insert > > > > > > > > statement for new items in a collection of a persistent entity > > when > > > > > > > > calling session.IsDirty(). > > > > > > > > > My configuration: > > > > > > > > * NHibernate 3.0.0.Alpha3 > > > > > > > > * An entity "Parent" with a collection of "Child" entities. > > One-to- > > > > > > > > many side is mapped as set, inverse, lazy and cascade > > all-delete- > > > > > > > > orphan. Many-to-one side is mapped as lazy. > > > > > > > > * All IDs are using the sequence generator. > > > > > > > > * Optimistic lock is by version column. > > > > > > > > * Session.FlushMode is Never. > > > > > > > > > My use-case: > > > > > > > > 1. Persistent Parent (already containing some Child entities) > > is > > > > > > > > loaded. > > > > > > > > 2. A new Child is added to the collection. > > > > > > > > 3. session.IsDirty() is called (UI checks, if it should enable > > the > > > > > > > > save button). > > > > > > > > 4. NHibernate executes a select statement for the ID of the new > > > > Child > > > > > > > > and queues an insert statement for the Child using its current > > > > > > > > (default) values. (Problem starts here: Why is it needed to get > > the > > > > ID > > > > > > > > of the new Child and queue an insert statement?) > > > > > > > > 4a. (Optional step) Some more new Childs are added. No more > > select > > > > > > > > statements are executed or insert statements are queued when > > > > calling > > > > > > > > session.IsDirty() because IsDirty() returns early because it > > knows > > > > it > > > > > > > > already has queued statements (very inconsistent behaviour in > > my > > > > > > > > opinion!) > > > > > > > > 5. User has to change a property of the Child to get rid of UI > > > > > > > > validation errors (a property is not allowed to be empty, but > > is by > > > > > > > > default to force the user to input something meaningful). > > > > > > > > 6. User saves the changes, session.Flush() is called. > > > > > > > > > Now NHibernate does the following: > > > > > > > > 1. Select statements for the new IDs of additional Childs from > > step > > > > 4a > > > > > > > > are executed. > > > > > > > > 2. The queued insert statement for the first new Child is > > executed. > > > > > > > > This statement uses the default values of the class and fails > > with > > > > an > > > > > > > > not null constraint error. > > > > > > > > 3. (If I disable the not null check in the DB) Parent version > > > > column > > > > > > > > is updated. > > > > > > > > 4. Additional childs from step 4a are inserted (with the > > already > > > > > > > > changed properties, so these statements are ok). > > > > > > > > 5. The first new Child is updated with the changed property. > > > > > > > > > I found the following Jira issue which already describes the > > > > problem, > > > > > > > > but it was rejected because it's "Expected behavior using > > > > identity": > > > > > > > >http://216.121.112.228/browse/NH-2136 > > > > > > > > But I'm using sequence, not identity, and still have the same > > > > problem. > > > > > > > > > Does anyone know if this is a bug at my side, a bug in > > NHibernate > > > > or > > > > > > > > just "by design" like for identiy IDs? > > > > > > > > > -- > > > > > > > > You received this message because you are subscribed to the > > Google > > > > > > Groups > > > > > > > > "nhusers" group. > > > > > > > > To post to this group, send email to nhus...@googlegroups.com. > > > > > > > > To unsubscribe from this group, send email to > > > > > > > > nhusers+unsubscr...@googlegroups.com<nhusers%2bunsubscr...@googlegroups.com> > > <nhusers%2bunsubscr...@googlegroups.com<nhusers%252bunsubscr...@googlegroups.com> > > > > > <nhusers%2bunsubscr...@googlegroups.com<nhusers%252bunsubscr...@googlegroups.com> > > <nhusers%252bunsubscr...@googlegroups.com<nhusers%25252bunsubscr...@googlegroups.com> > > > > > > > <nhusers%2bunsubscr...@googlegroups.com<nhusers%252bunsubscr...@googlegroups.com> > > <nhusers%252bunsubscr...@googlegroups.com<nhusers%25252bunsubscr...@googlegroups.com> > > > > > <nhusers%252bunsubscr...@googlegroups.com<nhusers%25252bunsubscr...@googlegroups.com> > > <nhusers%25252bunsubscr...@googlegroups.com<nhusers%2525252bunsubscr...@googlegroups.com> > > > > > > > > > . > > > > > > > > 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 nhus...@googlegroups.com. > > > > > > To unsubscribe from this group, send email to > > > > > > nhusers+unsubscr...@googlegroups.com<nhusers%2bunsubscr...@googlegroups.com> > > <nhusers%2bunsubscr...@googlegroups.com<nhusers%252bunsubscr...@googlegroups.com> > > > > > <nhusers%2bunsubscr...@googlegroups.com<nhusers%252bunsubscr...@googlegroups.com> > > <nhusers%252bunsubscr...@googlegroups.com<nhusers%25252bunsubscr...@googlegroups.com> > > > > > > > . > > > > > > 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 nhus...@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > nhusers+unsubscr...@googlegroups.com<nhusers%2bunsubscr...@googlegroups.com> > > <nhusers%2bunsubscr...@googlegroups.com<nhusers%252bunsubscr...@googlegroups.com> > > ... > > Erfahren Sie mehr ยป -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to nhus...@googlegroups.com. To unsubscribe from this group, send email to nhusers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
