To update or not to update...? Wrong answer for outer joins?

[jtuchel]

I was hunting for a strange bug for quite a while. Thomas gave me the final hint as to what might be going on.

The effect of what I see is that some changes to object read in a session are not recognized and therefor don't result in UPDATE statements.This potentially leads to catastrophic consequences.

Let me explain:

I have this web application where you can enter a few search criteria to find objects from the db. You can click on "Search" and get a list of objects matching your criteria. You can select one of these list entries and open an edit dialog. After you've changed data, you can click on SAVE and we commit the unit of work.

So far, nothing special is going on. The cheapest, most boring and simple CRUD stuff. Right? 

Wrong.

I have the situation where exactly that is NOT happening. You can select the object, open a dialog, change some data, click save and the UOW gets committed. Teh UOW commits successfully, but only because it doesn't issue any UPDATE statements. Because it found no changes between the buisiness object (which definitely has changed, both by values changed in the dialog and by calculations based on the changed input.

The result is that the business objects display wonderfully hanged values in the web browser and inspector, but they are out of sync with the database!!!

I seem to have found the reason.

The funny thing is: if I do all of this in a workspace: load an object by id, change a few values using the setters, commit the UOW, all is fine. But not in the Web App.

The reason seems to be that complex queries do not maintain the undoMap of the current Transaction. I added a bit of inspects and such and I found that when I directly load an object, it and its referenced objects are in the undoMap or the current UOW's transaction. But in case of my web application, they are not.

So what I had to do was to add an extra read to the list when the user selects an object from the list. When I hand this newly read object to the detail dialog, the objects end up in the undoMap and all changes get saved to the database on commit.

What I think is the problem is that the query for the list has a few (up to 8) alsoFetch: es with beOuterJoin's.

So my question: is this intended behavior or a bug?

Joachim

[Esteban Maringolo]

Hi Joachim,

I experienced something similar, albeit it didn't involve outer joins, but I got the same thing: no updates.

In some cases I resorted to using an explicit #save: , and later changed the inUnitOfWorkDo: to either a #transact: or #modify:in:. The latter does use a #transact: inside, so depending on the use case I prefer to use it over a raw #transact: where I have to register the "subject" prior to any change.

In the case of a web UI given the request/response cycle, the UoW should only happen within that cycle, which makes things somewhat convoluted (and slower) if you update on a "per field" basis using async http causing a req/res just for that field.

I don't know if it helps, but I hope it adds to the conversation.

Esteban A. Maringolo

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to glorp-group...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/ec8abe4d-2fdb-40f0-ba54-59457b156bebn%40googlegroups.com.

[jtuchel]

Esteban,

thanks for your comment. So you are the second Glorp user who confirms the problem - if it is a problem? I am still not sure if this is me using Glorp the wrong way.

The problem with our web app is that "Transactions" span multiple request/response cycles and even pages and so we'd have to put another layer of Memento objects on top of Glorp in order to track and "replay" all changes made over a number of request/response cycles within a transact: block. That would include tracking changes in the added layer and thus is error prone and somewhat feels like duplicating all that Glorp is actually about... Or am I missing an important detail about your suggestions?

Joachim