How to push code upstream in Glorp?

11 views
Skip to first unread message

jtuchel

unread,
Oct 29, 2020, 8:47:41 AM10/29/20
to glorp-group
Hi there,

We've been using VAST for quite a few years now. One of the things we use are the ...AndContinue variants of commitUnitOfWork and rollbackUnitOfWork.

I remember discussing a few fixes and improvements we've made back at ESUG in Brescia and Annecy. I think I talked to Niall back then.

As far as I can tell from the code I see in Pharo and my older version of VisualWorks PUL (I'm on Catalina, it doesn't run any more), the fixes we discussed haven't been integrated in Glorp. We're using them since 2016, the last update we made to the two methods were in 2018, so I'm quite confident they're not worse than the buggy originals in Glorp.

Since I have no idea how and where I could put such  (or, suggestions for ) fixes, I post the methods here in the hopes someone reads this and takes the time to comment or even integrate them in newer versions of Glorp.


commitUnitOfWorkAndContinue in its current implementation leads to wrong inserts in the same or the following (completely unrelated) Transaction, so it had to be changed to this implementation:


GlorpSession>>#commitUnitOfWorkAndContinue

    "Commit the current unit of work, but then keep going with the same set of registered objects, with their state updated to reflect current values."

    | registeredObjects oldUnit |

    currentUnitOfWork isNil ifTrue: [^self error: 'Not in unit of work'].

    "Remove all collections, because they could contain deleted objects"
    registeredObjects :=
        (oldUnit := currentUnitOfWork) registeredObjects reject: [:each | each isCollection].

    self commitUnitOfWork.

    (oldUnit deletedObjects, oldUnit newObjects) do: [:del| registeredObjects remove: del ifAbsent: []].

    self beginUnitOfWork.
    
"    self assert: (currentUnitOfWork newObjects isEmpty).
"   
    registeredObjects do: [:obj| self privateRegisterAsOld: obj. "circumvent isNew: check in GlorpSession>>register: because it will register objects as new that were just inserted in the old unit"].

    
 
There currently is no equivalent for rollbackUnitOfWorkAndContinue so we implemented our own:

  
GlorpSession>>#rollbackUnitOfWorkAndContinue
    "Rollback the current unit of work, but then keep going with the same set of registered objects, with their state updated to reflect current values."

    | registeredObjects |
    registeredObjects := OrderedCollection new.
    currentUnitOfWork isNil
        ifFalse: [

            "Reject collections, because they could contain new objects that will not be inserted due to this rollback"
            registeredObjects :=
                currentUnitOfWork registeredObjects reject: [:each | each isCollection].

            currentUnitOfWork newObjects do: [:each | registeredObjects remove: each].
            self rollbackUnitOfWork].
    self beginUnitOfWork.
    self registerAll: registeredObjects.






I'd be interested in comments on the code and hope someone involved in maintaining Glorp takes a look at this. I'd love to help in moving Glorp forward with my limited time and knowledge, but have no idea how I can do that if I am not a Cincom user/customer....








jtuchel

unread,
Nov 4, 2020, 2:28:42 AM11/4/20
to glorp-group
Just so that this message doesn't stand unanswered:

I received a personal message from one the devs at Cincom suggesting I send fixes to them directly.
Reply all
Reply to author
Forward
0 new messages