Still struggling with the simplest Transaction concepts...

Sometimes I feel I haven't understood the simplest of things about Glorp....

So here is a little test snippet:

|dbSess p|
dbSess := "log in a session, do a beginUnitOfWork"
p := (dbSess read: Person where: [:ea| ea id = 101]) first.
p name: 'Test1'.
dbSess commitUnitOfWork.
dbSess beginUnitOfWork.
p name: 'Test2'.
dbSess commitUnitOfWork.


It is very obvious this is wrong, but I have no idea why or how to do it right.

Why is this wrong?
Because in many (but by far not all) cases, not even the first change gets Updated on commitUnitOfWork. Even in cases where the first commit is converted into an UPDATE statement and a COMMIT, the second is absolutely never recognized as an update to be sent to the DB.

But what is it I am doing wrong? I guess the problem is that at the second commit, the Person instance is not registered with the session/uow any more, so I'd either have to re-read it or re-register it. The problem is that in more complex cases, I have no idea how many or which objects need to be re-read (is refresh: enough or does it have to be a read:where: ?) or re-registered.

But what puzzles me most is that the first UPDATE fails so often. This is a complete mystery to me...


How do people do things like this? Do you always start with a fresh UnitOfWork and read back all your objects before yor present them in a GUI for modification? Do you re-register objects before committing?

It may sound like a stupid beginners' question and maybe it is. I have been using Glorp for a while now and find out I am still on a beginner's level regularly... ;-)


Joachim

I can answer some of my questions, but am on the search for a recipe / best practices, because I have been coming back to problems of this kind over and over again.

So when I modify my example from the initial post to something like


|dbSess p|
dbSess := "log in a session, do a beginUnitOfWork"
p := (dbSess read: Person where: [:ea| ea id = 101]) first.
p name: 'Test1'.
dbSess commitUnitOfWork.
dbSess beginUnitOfWork.
dbSess register: p.   "<--- refreshing or read:where:'ing does solve thge problem for this simple case"
p name: 'Test2'.
dbSess commitUnitOfWork.


Then this works as expected. The problem is thatin a complex object graph, it is quite hard to find out which objects need to be registered. When you deal with hundreds or thousands of objects and only a hand full of these need modification, how do you manage that?

Sorry if this is boring and an RTFM question


Joachim






Am Dienstag, 3. April 2018 08:04:59 UTC+2 schrieb jtuchel:

Sometimes I feel I haven't understood the simplest of things about Glorp....

So here is a little test snippet:

|dbSess p|
dbSess := "log in a session, do a beginUnitOfWork"
p := (dbSess read: Person where: [:ea| ea id = 101]) first.
p name: 'Test1'.
dbSess commitUnitOfWork.
dbSess beginUnitOfWork.
p name: 'Test2'.
dbSess commitUnitOfWork.


It is very obvious this is wrong, but I have no idea why or how to do it right.

Why is this wrong?
Because in many (but by far not all) cases, not even the first change gets Updated on commitUnitOfWork. Even in cases where the first commit is converted into an UPDATE statement and a COMMIT, the second is absolutely never recognized as an update to be sent to the DB.

But what is it I am doing wrong? I guess the problem is that at the second commit, the Person instance is not registered with the session/uow any more, so I'd either have to re-read it or re-register it. The problem is that in more complex cases, I have no idea how many or which objects need to be re-read (is refresh: enough or does it have to be a read:where: ?) or re-registered.

But what puzzles me most is that the first UPDATE fails so often. This is a complete mystery to me...


How do people do things like this? Do you always start with a fresh UnitOfWork and read back all your objects before yor present them in a GUI for modification? Do you re-register objects before committing?

It may sound like a stupid beginners' question and maybe it is. I have been using Glorp for a while now and find out I am still on a beginner's level regularly... ;-)


Joachim