Fwd: Re: [Glorp-development] 'Dirty' queries

X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 13 Dec 2006 11:31:21 -0500
To: "Mark Plas" <[hidden email]>,
        "Antony Blakey" <[hidden email]>
From: Alan Knight <[hidden email]>
X-magma-MailScanner-Information: Magma Mailscanner Service
X-magma-MailScanner: Clean
X-Spam-Status:
X-Spam-Score: 1.4 (+)
X-Spam-Report: Spam Filtering performed by sourceforge.net.
        See http://spamassassin.org/tag/ for more details.
        Report problems to
         http://sf.net/tracker/?func=add&group_id=1&atid=200001
        1.0 FORGED_RCVD_HELO       Received: contains a forged HELO
        0.2 HTML_TEXT_AFTER_BODY BODY: HTML contains text after BODY close tag
        0.0 HTML_MESSAGE           BODY: HTML included in message
        0.3 HTML_10_20             BODY: Message is 10% to 20% HTML
Cc: [hidden email]
Subject: Re: [Glorp-development] 'Dirty' queries
X-BeenThere: [hidden email]
X-Mailman-Version: 2.1.8
List-Id: <glorp-development.lists.sourceforge.net>
List-Unsubscribe: < https://lists.sourceforge.net/lists/listinfo/glorp-development >,
         <[hidden email] >
List-Archive: < http://sourceforge.net/mailarchive/forum.php?forum=glorp-development >
List-Post: <[hidden email]>
List-Help: <[hidden email] >
List-Subscribe: < https://lists.sourceforge.net/lists/listinfo/glorp-development >,
         <[hidden email] >
Sender: [hidden email]
X-pstn-levels:     (S:99.90000/99.90000 R:95.9108 P:95.9108 M:97.0282 C:98.6951 )

If you want to eventually commit those changes, then perhaps the easiest way is not to roll back the database transaction.

That is, start a database transaction, do some stuff, commit the unit of work (you might want saveAndContinue, which keeps the same objects registered in a new unit of work), do some more work, commit the unit of work again, and when you're entirely finished, commit the database transaction. That avoids writing those changes twice, although it does make you keep a transaction open longer.

Most of the database round-trip tests work in roughly the way you talk about initially. That is, they start a database transaction, populate some test data, do the tests, then roll back the database transaction. That way it's very easy to clean up the database, and you should never have to worry about a failed test leaving garbage in the database, no matter what the nature of the failure or where it occurs.

It's possible that simply removing the
   currentUnitOfWork := nil
line in commitUnitOfWork would have roughly the desired effect. On the other hand, it seems a bit unpredictable to me. There are side-effects that happen in the process of writing. Sequence numbers get generated, things can be marked deleted in the cache. I think I would be more inclined to just leave the transaction open in the database.

At 09:11 AM 12/13/2006, Mark Plas wrote:

I've taken a glance at the implementation of commitUnitOfWork and it
indeed 'forgets' the changes after the method finishes, which is
probably what you'd expect from reading the method name.

I would be needing an additional mechanism to flush the changes
temporarily without forgetting them so that I still have a chance to
commit them later on in the process. I'd have to dig a bit deeper in the
code to see whether a thing like this would be possible.

-----Original Message-----
From: Antony Blakey [ [hidden email]]
Sent: woensdag 13 december 2006 14:24
To: Mark Plas
Cc: [hidden email]
Subject: Re: [Glorp-development] 'Dirty' queries


On 13/12/2006, at 11:45 PM, Mark Plas wrote:

> Just to be sure, if you do
> - commitUnitOfWork
> - query
> - rollback transaction
> - commitUnitOfWork
> - commit transaction
>
> Will the changes you made in the unitOfWork be committed ?

No for the first, yes for the second.

> Or does the
> unitOfWork 'forget' its changes after you do a commitUnitOfWork ?

The transaction contains units of work - they don't span 
transactions. The unit of work is the thing that records changes and 
writes them out to the DB, at which point it forgets it's changes. So 
IMO the term 'commit' is overloaded when applied to units of work 
because it's not a commit in a transactional sense (although I think 
that if you use only units of work and no transaction delimiters then 
they conflate).

In any case, this is how it works for me, but my understanding is 
purely from reading source, starting from the test cases.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

When I hear somebody sigh, 'Life is hard,' I am always tempted to 
ask, 'Compared to what?'
   -- Sydney Harris



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Glorp-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/glorp-development

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Glorp-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/glorp-development