I have a secnario where I fetch a collection of entities. Each entity in the collection has a 1:N member collection of related entities that I make changes to. It would be cool if there was a similar member for ContainsDirtyContents for the parent (e.g. parentEntity.ContainsDirtyChildren) that identifies that children have been changed, otherwise, I have to iterate all the parent entities and check the member collection's ContainsDirtyContents property to see if child records have been changed.

Another cool operation would simply to make ContainsDirtyContents == true if any objects in the object graph have been changed.

Just a thought.

Devildog74 wrote:

I have a secnario where I fetch a collection of entities. Each entity in the collection has a 1:N member collection of related entities that I make changes to. It would be cool if there was a similar member for ContainsDirtyContents for the parent (e.g. parentEntity.ContainsDirtyChildren) that identifies that children have been changed, otherwise, I have to iterate all the parent entities and check the member collection's ContainsDirtyContents property to see if child records have been changed.

That would mean a lot of eventhandler voodoo behind the scenes and also mean that children are part of the parent. For direct children it might be doable, but what if in the graph customer <-order<-orderdetails<-products, the product changes? How's the customer notified? 'orderdetails' isn't changed. Should 'customer' even be notified? I'm thinking that it shouldn't.

Another cool operation would simply to make ContainsDirtyContents == true if any objects in the object graph have been changed. Just a thought.

I'm not sure you want this. Events can seriously bring down performance. For example, if the graph has 100 objects, and you save them all in a transaction, at commit, each object will fire an event that it has been saved succesfully and its parent will reset that contains dirty contents. When that happens, perhaps some other code gets triggered, and therefore slow down performance.

I know how slow events can be, the llblgen pro designer is build on top of a lot of events, to keep everything in sync. I had to implement two types of events (changed and redraw) to make the system performant, otherwise too many events were fired sometimes, triggering redraw code too many times.

But youre the vodoo master, hehe.

I agree that it would get messy and how you would know when to stop is probably the question of the day.

I actually ended up with this code, that isnt too bad and works.

            ValidateAnswers(surveys);
                    foreach (SurveyEntity survey in surveys)
                    {
                        if (survey.SurveyOption.ContainsDirtyContents)
                        {
                            UnitOfWork2 uow = new UnitOfWork2();
                            uow.AddCollectionForSave(surveys, false, true);
                            SurveyController.CommitUnitOfWork(uow,true);
                            break;
                        }
                    }

My intention is simply preventing the runtime from checking if there are things to do if we can preemtively determine if there is work to be done.

Devildog74 wrote:

But youre the vodoo master, hehe.

I agree that it would get messy and how you would know when to stop is probably the question of the day.

I actually ended up with this code, that isnt too bad and works.

            ValidateAnswers(surveys);
                    foreach (SurveyEntity survey in surveys)
                    {
                        if (survey.SurveyOption.ContainsDirtyContents)
                        {
                            UnitOfWork2 uow = new UnitOfWork2();
                            uow.AddCollectionForSave(surveys, false, true);
                            SurveyController.CommitUnitOfWork(uow,true);
                            break;
                        }
                    }

My intention is simply preventing the runtime from checking if there are things to do if we can preemtively determine if there is work to be done.

Though, would that be any more efficient? I mean: if you have to check everything, the savelogic does that too.

I dont know if it would be more effecient, as I dont know what hoops the dqe must go through to determine if and when to parse objects to create tsql.

However, I do know that my validate method may or may not update an entities collection. Given that I dont know what happens internally, but I do know that iterating a few collections and checking a boolean flag on a member collection is a relatively quick operation compared to what might happen internally, I can stop the internal checking if it doesnt need to.

Or I could have just been overcomplicating things when I though it might be a good idea to stop llblgen from checking to see if it needed to do work if I could determine if it really needed to, does this make any sense.....?

If you send a graph to the save routine, the graph is walked for dirty entities, these are saved, the rest are ignored (but their related entities are examined). This of course takes a little bit of time (just some object walking and checking a flag, is pretty fast), so if you know beforehand which entities are dirty, it's a bit faster, though to get there, you need extra code, so in the end, I don't think it will really matter much.