Greetings, UnitOfWork are a great way to bundle transactions together and execute them BUT the thing I loose with this is the nice reporting feedback I used to get from the adapter methods like FetchEntity, DeleteEntity, DeleteEntitiesDirectly,...etc. The Boolean/Integer return values are valuable and usefull information. Why don't a UOW return a hashtable of return values for each of its bundled transactions so that we can access the required retrun value like we would access a normal dictionary collection ??

Because all actions are seen as 1 atomic action: Commit. So if Commit succeeds, all actions were succesful, so IMHO it's not of any value to know each individual action was succesful. Or do you mean something else?

Otis wrote:

Because all actions are seen as 1 atomic action: Commit. So if Commit succeeds, all actions were succesful, so IMHO it's not of any value to know each individual action was succesful. Or do you mean something else?

I think Frans is right about the commit being an atomic action, but it would be nice to have some more info just before the commit if called.

I do not know if Omar is thinking of the same type of situation, but this is the situation i'm facing at the moment: I fetch a lot of data from a number of tables, do a lot of complicated processing and then save the updated/inserted entities. Now, I want to write some statistics to a log:

Invoices:
-- 524 inserted
-- 135 updated
-- 12 unchanged

This is also an issue with the EntityCollection, since i only have a Count property (and the DirtyEntities.Count).

wvnoort wrote:

Otis wrote:

Because all actions are seen as 1 atomic action: Commit. So if Commit succeeds, all actions were succesful, so IMHO it's not of any value to know each individual action was succesful. Or do you mean something else?

I think Frans is right about the commit being an atomic action, but it would be nice to have some more info just before the commit if called.

I do not know if Omar is thinking of the same type of situation, but this is the situation i'm facing at the moment: I fetch a lot of data from a number of tables, do a lot of complicated processing and then save the updated/inserted entities. Now, I want to write some statistics to a log:

Invoices:
-- 524 inserted
-- 135 updated
-- 12 unchanged

This is also an issue with the EntityCollection, since i only have a Count property (and the DirtyEntities.Count).

In 1.0.2005.1, the recursive save code has been reworked to pre-calculate the insert and update queues prior to actually calling the save actions on them. This means that after commit, these queues are still available. You can call: GetInsertQueue and GetUpdateQueue, which give you the exact queues as they've been processed.

Otis wrote:

In 1.0.2005.1, the recursive save code has been reworked to pre-calculate the insert and update queues prior to actually calling the save actions on them. This means that after commit, these queues are still available. You can call: GetInsertQueue and GetUpdateQueue, which give you the exact queues as they've been processed.

1.0.2005.1 - That's still a beta, isn't it? I will tag the code, so i can replace/repair it when it is officially released.

Are these two methods of the EntityCollection?

No of unit of work.

yes still in beta.

Thanks wvnoort.. thats exactly what I was shooting for. Frans.. if I have a DAL generated with the current LLBL version: 1- do I have to re-egenerate DAL to use the new LLBL 2- my BL classes use the extended entity templates. Do these templates work with the new LLBL 3- any time frame for when the beta will be over

omar wrote:

Thanks wvnoort.. thats exactly what I was shooting for. Frans.. if I have a DAL generated with the current LLBL version: 1- do I have to re-egenerate DAL to use the new LLBL

Yes.

2- my BL classes use the extended entity templates. Do these templates work with the new LLBL

Updated extended adapter entity templates are shipped with the beta

3- any time frame for when the beta will be over

I hoped this week, but I think it will be next week.