ProDataset MERGE-CHANGES copy-all-mode unexpected behaviour?

Posted by Mike Fechner on 13-Feb-2015 09:04

Hi all, is this really expected behaviour? Tested on 11.5, 11.3 and 10.2B

I have a ProDataset with two tables, let's call them eCustomer and eSalesRep. eCustomer has a BEFORE-TABLE, eSalesRep does not.

I create two customer records and two salesrep records, turn on TRACKING-CHANGES for eCustomer and modify one record.

Then I get the changes dataset ...

hChanges:GET-CHANGES (DATASET dsCustomer:HANDLE, TRUE) .

and as expected the hChanges dataset contains a single customer record and no salesrep.

Then I use the MERGE-CHANGES method (directly without calling into any data access layer to process changes):

hChanges:MERGE-CHANGES (DATASET dsCustomer:HANDLE, TRUE) .

My expectation is, that MERGE-CHANGES copies data from the hChanges dataset to the dataset dsCustomer. In a real scenario this would update the client side eCustomer table with data updated during processing the changes on the AppServer. The copy-all-mode (the logical parameter) should control - to my understanding - that unmodified records (from tables with or without a BEFORE TABLE) from the hChanges dataset are merged into dsCustomer as well.

But why the heck, are the two unmodified salesrep records getting copied form dsCustomer to hChanges dataset????

And if - for what ever reason - that would be expected - why is the unmodified customer NOT copied in that direction as well????

I have a message before and after the MERGE-CHANGES:

MESSAGE "changes dataset" SKIP
"Customer" hChanges::eCustomer:TABLE-HANDLE:HAS-RECORDS
CountRecords(hChanges::eCustomer:HANDLE) SKIP
"SalesRep" hChanges::eSalesRep:TABLE-HANDLE:HAS-RECORDS
CountRecords(hChanges::eSalesRep:HANDLE)
SKIP
VIEW-AS ALERT-BOX.

Message before MERGE-CHANGES

changes dataset
Customer yes 1
SalesRep no 0

Message after MERGE-CHANGES

changes dataset
Customer yes 1
SalesRep yes 2

Source code attached.

OpenEdge Development - Forum

All Replies

Posted by Jeff Ledbetter on 13-Feb-2015 09:31

Is it because you are passing TRUE for the copy-all mode to MERGE-CHANGES?
 
“When TRUE, the AVM merges all after-image table rows whether or not they contain changes. In this case, the temp-table in the original ProDataSet object must have a unique primary index that the AVM can use to find each corresponding row from the after-image table (since unchanged rows do not have a corresponding row in the before-image table). When a corresponding row is not found in the original ProDataSet object, the AVM creates a new row using the row from the after-image table. When FALSE, the AVM merges only after-image table rows that contain changes. The default value is FALSE.”
 
Jeff Ledbetter
skype: jeff.ledbetter
 
[collapse]
From: Mike Fechner [mailto:bounce-mikefechner@community.progress.com]
Sent: Friday, February 13, 2015 9:05 AM
To: TU.OE.Development@community.progress.com
Subject: [Technical Users - OE Development] ProDataset MERGE-CHANGES copy-all-mode unexpected behaviour?
 
Thread created by Mike Fechner

Hi all, is this really expected behaviour? Tested on 11.5, 11.3 and 10.2B

I have a ProDataset with two tables, let's call them eCustomer and eSalesRep. eCustomer has a BEFORE-TABLE, eSalesRep does not.

I create two customer records and two salesrep records, turn on TRACKING-CHANGES for eCustomer and modify one record.

Then I get the changes dataset ...

hChanges:GET-CHANGES (DATASET dsCustomer:HANDLE, TRUE) .

and as expected the hChanges dataset contains a single customer record and no salesrep.

Then I use the MERGE-CHANGES method (directly without calling into any data access layer to process changes):

hChanges:MERGE-CHANGES (DATASET dsCustomer:HANDLE, TRUE) .

My expectation is, that MERGE-CHANGES copies data from the hChanges dataset to the dataset dsCustomer. In a real scenario this would update the client side eCustomer table with data updated during processing the changes on the AppServer. The copy-all-mode (the logical parameter) should control - to my understanding - that unmodified records (from tables with or without a BEFORE TABLE) from the hChanges dataset are merged into dsCustomer as well.

But why the heck, are the two unmodified salesrep records getting copied form dsCustomer to hChanges dataset????

And if - for what ever reason - that would be expected - why is the unmodified customer NOT copied in that direction as well????

I have a message before and after the MERGE-CHANGES:

MESSAGE "changes dataset" SKIP
"Customer" hChanges::eCustomer:TABLE-HANDLE:HAS-RECORDS
CountRecords(hChanges::eCustomer:HANDLE) SKIP
"SalesRep" hChanges::eSalesRep:TABLE-HANDLE:HAS-RECORDS
CountRecords(hChanges::eSalesRep:HANDLE)
SKIP
VIEW-AS ALERT-BOX.

Message before MERGE-CHANGES

changes dataset
Customer yes 1
SalesRep no 0

Message after MERGE-CHANGES

changes dataset
Customer yes 1
SalesRep yes 2

Source code attached.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by Mike Fechner on 13-Feb-2015 10:13

Jeff, I am not convinced….
 
1st that would not explain, why the eCustomer in the changes dataset does still only contain a single record. Following your reading the eCusstomer in the changes dataset should contain two records. That would mean that the after-image for tables with and tables without a before-image table are treated differently.
 
2nd The is all under the intro:
 
“Merges the changed rows of all temp-tables or a single temp-table in a source ProDataSet object loaded with the GET-CHANGES( ) method into the corresponding rows of all temp-tables or a single temp-table (respectively) in the original (target) ProDataSet object.”
 
…. Into the corresponding tows … in the original ProDataset …
 
So there should not be any data-movement from source to change at all. This is MERGE-CHANGES, not GET-CHANGES
 
3rd Imaging 100.000 eSalesRep records in the original dataset…. It can’t be a clever idea to copy them to a dataset (blowing up the DBI file) which most likely get’s deleted in the next line of code.
 
 
Von: Jeff Ledbetter [mailto:bounce-jeffledbetter@community.progress.com]
Gesendet: Freitag, 13. Februar 2015 16:33
An: TU.OE.Development@community.progress.com
Betreff: RE: [Technical Users - OE Development] ProDataset MERGE-CHANGES copy-all-mode unexpected behaviour?
 
Reply by Jeff Ledbetter
Is it because you are passing TRUE for the copy-all mode to MERGE-CHANGES?
 
“When TRUE, the AVM merges all after-image table rows whether or not they contain changes. In this case, the temp-table in the original ProDataSet object must have a unique primary index that the AVM can use to find each corresponding row from the after-image table (since unchanged rows do not have a corresponding row in the before-image table). When a corresponding row is not found in the original ProDataSet object, the AVM creates a new row using the row from the after-image table. When FALSE, the AVM merges only after-image table rows that contain changes. The default value is FALSE.”
 
Jeff Ledbetter
skype: jeff.ledbetter
 
[collapse]
From: Mike Fechner [mailto:bounce-mikefechner@community.progress.com]
Sent: Friday, February 13, 2015 9:05 AM
To: TU.OE.Development@community.progress.com
Subject: [Technical Users - OE Development] ProDataset MERGE-CHANGES copy-all-mode unexpected behaviour?
 
Thread created by Mike Fechner

Hi all, is this really expected behaviour? Tested on 11.5, 11.3 and 10.2B

I have a ProDataset with two tables, let's call them eCustomer and eSalesRep. eCustomer has a BEFORE-TABLE, eSalesRep does not.

I create two customer records and two salesrep records, turn on TRACKING-CHANGES for eCustomer and modify one record.

Then I get the changes dataset ...

hChanges:GET-CHANGES (DATASET dsCustomer:HANDLE, TRUE) .

and as expected the hChanges dataset contains a single customer record and no salesrep.

Then I use the MERGE-CHANGES method (directly without calling into any data access layer to process changes):

hChanges:MERGE-CHANGES (DATASET dsCustomer:HANDLE, TRUE) .

My expectation is, that MERGE-CHANGES copies data from the hChanges dataset to the dataset dsCustomer. In a real scenario this would update the client side eCustomer table with data updated during processing the changes on the AppServer. The copy-all-mode (the logical parameter) should control - to my understanding - that unmodified records (from tables with or without a BEFORE TABLE) from the hChanges dataset are merged into dsCustomer as well.

But why the heck, are the two unmodified salesrep records getting copied form dsCustomer to hChanges dataset????

And if - for what ever reason - that would be expected - why is the unmodified customer NOT copied in that direction as well????

I have a message before and after the MERGE-CHANGES:

MESSAGE "changes dataset" SKIP
"Customer" hChanges::eCustomer:TABLE-HANDLE:HAS-RECORDS
CountRecords(hChanges::eCustomer:HANDLE) SKIP
"SalesRep" hChanges::eSalesRep:TABLE-HANDLE:HAS-RECORDS
CountRecords(hChanges::eSalesRep:HANDLE)
SKIP
VIEW-AS ALERT-BOX.

Message before MERGE-CHANGES

changes dataset
Customer yes 1
SalesRep no 0

Message after MERGE-CHANGES

changes dataset
Customer yes 1
SalesRep yes 2

Source code attached.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by Peter Judge on 13-Feb-2015 11:06

Smells like a bug to me too.

If you dump out the changes dataset after GET-CHANGES() and after MERGE-CHANGES(), they are different. I would not expect them to be, since the direction of the merge should be from changes --> dsCustomer.  

hChanges:write-json('file', session:temp-dir + 'changes-1.json', yes, ?, ?, ?, yes).
/* there's a changes-2 version for dumping after merge-changes() */

changes-1.json has a single eCustomer record (plus the before-image tracking).

changes-2.json has a single eCustomer record (plus the before-image tracking) AND 2 eSalesrep records.

Note that this doesn't seem to be influenced by the copy-all-mode flag

-- peter

Posted by Fernando Souza on 13-Feb-2015 13:43

Yes, this is a bug. We are not supposed to be copying data into the changed dataset. As a workaround, you can define a before-table for the child table (eSalesRep), and you will see the expected behavior.

Please, report this via Technical Support so a bug can be logged.

Posted by Mike Fechner on 13-Feb-2015 14:45

Thanks Peter, thanks Fernando! Will log the case with ETSC.
 

Posted by Mike Fechner on 13-Feb-2015 15:00

Case 00304041

This thread is closed