Hi Brent, I can't reproduce the problem you're having. I tried changing ChangeSummaryTestCase so that it creates the datagraph and then calls beginLogging() and it still works fine for me. I'll need you to give me a simple test program that reproduces the problem you're seeing.
The behavior of summarize() hasn't changed since SDO1. You should be able to just call summarize() as you did before. You shouldn't be calling beginLogging() after that though, because it will still be logging. That's the same as it was in SDO 1 - summarize() never turned off logging, it just refreshed the current result. Frank. Brent Daniel <[EMAIL PROTECTED]> wrote on 01/31/2006 02:30:38 PM: > Frank, > > I still have the issue that change recording is not taking place if > beginRecording() is called after a DataGraph has already been built. > Everything seems to work fine if it is turned on before initially creating > DataObject instances. I traced it down as far as > DataObjectImpl.eNotificationRequired(), which returns false because the > changeRecorder is null. > > I've also tried calling beginRecording(), building the data graph, calling > endRecording() and beginRecording() again. In this case, there is a > changeRecorder object there, but for some reason the changes still do not > show up in the change history. > > The change to the behavior of summarize() is a problem for the DAS. > Currently, we are calling summarize() to stop recording because endLogging() > followed by beginLogging() will blow away the change history. With > summarize() and resumeLogging(), if we encounter an error while pushing the > changes to the database we can return the data graph in the state that it > was sent to us and allow the user to work around the problem. Using > endLogging(), the user is forced to start over. We don't really need a > summarize() command, but we do need the change history to be available to us > without having to call endLogging(). Not sure if this has changed since the > SDO1 implementation, but we have always had to call either summarize() or > endLogging() to force the runtime to populate the change history. > > Brent > > > On 1/31/06, Frank Budinsky (JIRA) <[EMAIL PROTECTED]> wrote: > > > > [ http://issues.apache.org/jira/browse/TUSCANY-21?page=all ] > > > > Frank Budinsky resolved TUSCANY-21: > > ----------------------------------- > > > > Resolution: Invalid > > > > I don't think these are problems: > > > > 1) The EMF adapter list (eAdapters) isn't used to attach the change > > recorder to dataobjects in SDO2. There is a dedicated instance variable ( > > DataObjectImpl.changeRecorder) that is used for this. So even though you > > don't see an adapter, it still should be recording changes after you call > > beginLogging(). > > > > 2) You need to call endLogging() before you call resumeLogging(). The > > summarize() method doesn't stop logging so calling resumeLogging() after > > summarize() will fail. Note that summarize() and resumeLogging() are > > implementation methods and not part of the SDO2 API, so use of them should > > be avoided. > > > > > SDO change summary not working properly > > > --------------------------------------- > > > > > > Key: TUSCANY-21 > > > URL: http://issues.apache.org/jira/browse/TUSCANY-21 > > > Project: Tuscany > > > Type: Bug > > > Components: Java SDO Implementation > > > Reporter: Brent Daniel > > > > > > > > I'm having trouble with the change history in the SDO 2 implementation. > > > 1) The normal pattern in the DAS is to build a data graph and then turn > > on change recording. When you do this, the adapter for the change recorder > > doesn't seem to get added to the DataObject instances in the graph, so no > > changes are recorded. > > > 2) You can't do a summarize() and then resumeLogging(). The > > implementation will complain that logging is still enabled. > > > > -- > > This message is automatically generated by JIRA. > > - > > If you think it was sent incorrectly contact one of the administrators: > > http://issues.apache.org/jira/secure/Administrators.jspa > > - > > For more information on JIRA, see: > > http://www.atlassian.com/software/jira > > > >
