alsoFetch:ed objects aren't registered in the Transaction's undoMap???

[jtuchel]

Here I am, once again a bit helpless...

There is this interesting bug in my program which leads to changes to some objects aren't recognized and thus not saved on commitUnitOfWork, although the business objects are changed.

After quite some debugging I found that objects fetched using alsoFetch: are not registered with the current ObjectTransaction.

As always, the sitiuation is a bit complex. We do have search/filter dialogs in which you can search for business transactions. We do a few alsoFetch: es with beOuterJoin to fill the list as fast as possible. Then  we have this feature to select multiple entries in the resulting table and change something (like the debit account). It turns our that this mass operation does save a new version of the business transaction, but does not save the change of the debit account, because there is no entry for it in the ObjectTransaction's undoMap. So Glorp thinks there is some change, but doesn't actually identify the change itself.

I set a Breakpoint in ObjectTransaction>>#register: and was a bit shocked / surprised that the alsoFetch:ed objects aren't registered when the list of objects is read.

Interestingly. If I open a selected business transaction in a detail dialog, the debitAccount is being registered, and the same changes gets saved on commit.

Also, if I remove the alsoFetch: from our seartch dialog's query, the debitAccounts get registered and the mass operation gets saved correctly.

The downside is: most uses of the list will not involve mass operations to change debit or credit accounts and not alsoFetch: ing them slows the list down . One single SQL query is replaced by a plethora of queries, depending on how complex the search filters are...

So my main question: is this missing registration of alsoFetch:ed objects by design or is this a bug?

If it is a bug, I would love to get it fixed - or maybe it already is fixed in newer versions of Glorp (who knows?) and may or may not make its way to non-Cincom dialects.... If it is by design, I will probably better look into preparing mass  operations by re-reading objects without alsoFetch: before changing them.

Any ideas? Thoughts?

Joachim

[jtuchel]

Hi

I tried to write a test case for this strange problem (bug? phenomenon? dunno!) and it seems there need to be very special circumstances for this to happen. Maybe this only happens when you join three or more tables or such. Just alsoFetch: ing objects through one foreign key is not enough to irritate Glorp.
I am still on the hunt, will come back when I find out more. 

Joachim