Bug #10519: ProDataset WRITE-XML issue on nested PARENT-ID-RELATION - Base Language - Golden Code Redmine

Bug #10519

ProDataset WRITE-XML issue on nested PARENT-ID-RELATION

Added by Teodor Gorghe 11 months ago. Updated 9 months ago.

Status:

Test

Priority:

Normal

Assignee:

Teodor Gorghe

Target version:

Start date:

Due date:

% Done:

100%

billable:

vendor_id:

GCD

case_num:

version_reported:

version_resolved:

reviewer:

Alexandru Lungu, Constantin Asofiei

production:

env_name:

topics:

Related issues

History

#2 Updated by Teodor Gorghe 11 months ago

Suppose we have a ProDataSet structure like this:

RootNode
|
|- node1
|  |
|  |- node11
|  |  |
|  |  |- commonTable
|  |  |
|  |  |- commonTable
|  |
|  |- node11
|     |
|     |- commonTable
|
|- node2
   |
   |- commonTable

There are multiple issues:

WRITE-XML: When SERIALIZE-HIDDEN is set to true, the second node11 is not created, but the contents get inserted into XML. You will end up with a commonTable node into node1. When closing the XML element (the supposed not to be closed is the second node11, but node1 is closed instead. I goes into the root node and WRITE-XML fails. From investigation, I have found that there is an issue with hasChild flag.
WRITE-XML, but WRITE-JSON also suffers from this issue: When inserting child records into the element node, all records from the child temp-table gets inserted. There should be inserted only the records matching the parent id with the parent recid.

ABL code ABL code

BLOCK-LEVEL ON ERROR UNDO, THROW.

USING OpenEdge.Core.Assert FROM PROPATH.

CLASS tests.TestWriteXmlParentIdRelation:
    DEFINE TEMP-TABLE rootNode
        FIELD name AS CHARACTER.

    DEFINE TEMP-TABLE node1
        FIELD name AS CHARACTER
        FIELD rootNode AS RECID.

    DEFINE TEMP-TABLE node11
        FIELD name AS CHARACTER
        FIELD node1 AS RECID.

    DEFINE TEMP-TABLE node2
        FIELD name AS CHARACTER
        FIELD rootNode AS RECID.

    DEFINE TEMP-TABLE commonTable
        FIELD parent_id AS RECID
        FIELD name AS CHARACTER.

    DEFINE DATASET dsExample XML-NODE-TYPE "HIDDEN" FOR rootNode, node1, node11, node2, commonTable
        PARENT-ID-RELATION REL1 FOR rootNode, node1 PARENT-ID-FIELD rootNode
        PARENT-ID-RELATION REL2 FOR rootNode, node2 PARENT-ID-FIELD rootNode
        PARENT-ID-RELATION REL3 FOR node1, node11 PARENT-ID-FIELD node1
        PARENT-ID-RELATION REL4 FOR node2, commonTable PARENT-ID-FIELD parent_id
        PARENT-ID-RELATION REL5 FOR node11, commonTable PARENT-ID-FIELD parent_id.

    @Setup.
    METHOD PUBLIC VOID PopulateDataset():
        DATASET dsExample:EMPTY-DATASET ().

        CREATE commonTable.
        commonTable.name = "c1".

        CREATE node11.
        node11.name = "node11".
        commonTable.parent_id = RECID(node11).

        CREATE commonTable.
        commonTable.name = "c2".
        commonTable.parent_id = RECID(node11).

        CREATE node1.
        node1.name = "node1".
        node11.node1 = RECID(node1).

        CREATE rootNode.
        rootNode.name = "Root".
        node1.rootNode = RECID(rootNode).

        CREATE commonTable.
        commonTable.name = "c3".

        CREATE node11.
        node11.name = "node11_sc".
        commonTable.parent_id = RECID(node11).
        node11.node1 = RECID(node1).

        CREATE node2.
        node2.name = "node2".
        node2.rootNode = RECID(rootNode).

        CREATE commonTable.
        commonTable.name = "c4".
        commonTable.parent_id = RECID(node2).

    END METHOD.

    @Test.
    METHOD PUBLIC VOID TestWriteXmlLongchar():
        DEFINE VARIABLE rId       AS RECID    NO-UNDO.
        DEFINE VARIABLE cOutput   AS LONGCHAR NO-UNDO.

        DATASET dsExample:WRITE-XML ("longchar", cOutput, TRUE).
        COPY-LOB cOutput TO FILE "output-xml.txt".
    END METHOD.

    @Test.
    METHOD PUBLIC VOID TestWriteJsonlLongchar():
        DEFINE VARIABLE rId       AS RECID    NO-UNDO.
        DEFINE VARIABLE cOutput   AS LONGCHAR NO-UNDO.

        DATASET dsExample:WRITE-JSON ("longchar", cOutput, TRUE).
        COPY-LOB cOutput TO FILE "output-json.txt".
    END METHOD.
END CLASS.

#3 Updated by Teodor Gorghe 11 months ago

Created task branch 10519.
I have a fix for the first issue, which will come very soon.
For the second issue, there are no issues with WRITE-XML and WRITE-JSON, but rather, node11 and node2 have the same recid (4GL generates unique recid from the entire session, two temp-table cannot have the same recid).

#4 Updated by Teodor Gorghe 11 months ago

Status changed from New to WIP

#5 Updated by Teodor Gorghe 11 months ago

Committed revision 16146 on task branch 10519a:
- Reset hasChild flag to initial state while iterating through childs.

#6 Updated by Teodor Gorghe 11 months ago

There is a big problem on how we generate the recid field from a record:

// Procedure entry point
// Temp table definitions

CREATE node11.
CREATE node2.

// In 4GL, the RECID is different between two temp-table, but on FWD, is the same.

The testcase #10519-2 shows why this is not right.

Please also check this scenario:

We use READ-XML to import the dataset from XML, with this payload: Payload

<?xml version="1.0"?>
<rootNode xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <name>Root</name>
  <node1>
    <name>node1</name>
    <node11>
      <name>node11</name>
      <commonTable>
        <name>c1</name>
      </commonTable>
      <commonTable>
        <name>c2</name>
      </commonTable>
    </node11>
    <node11>
      <name>node11_sc</name>
      <commonTable>
        <name>c3</name>
      </commonTable>
    </node11>
  </node1>
  <node2>
    <name>node2</name>
    <commonTable>
      <name>c4</name>
    </commonTable>
  </node2>
</rootNode>

On WRITE-XML we get back this payload (FWD): Payload

<?xml version='1.0'?>
<rootNode xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <name>Root</name>
  <node1>
    <name>node1</name>
    <node11>
      <name>node11</name>
      <commonTable>
        <name>c1</name>
      </commonTable>
      <commonTable>
        <name>c2</name>
      </commonTable>
      <commonTable>
        <name>c4</name>
      </commonTable>
    </node11>
    <node11>
      <name>node11_sc</name>
      <commonTable>
        <name>c3</name>
      </commonTable>
    </node11>
  </node1>
  <node2>
    <name>node2</name>
    <commonTable>
      <name>c1</name>
    </commonTable>
    <commonTable>
      <name>c2</name>
    </commonTable>
    <commonTable>
      <name>c4</name>
    </commonTable>
  </node2>
</rootNode>

As you can see, this is completely wrong, c4 shouldn't be in node11 and c1/c2 in node2.

I think this requires H2 modifications.

#7 Updated by Constantin Asofiei 11 months ago

Are you saying that if you call CREATE twice one after the other, for different temp-tables, both records will have the same PK in FWD?

#8 Updated by Alexandru Lungu 11 months ago

There are limitations on how we can assign recid to _temp in FWD. There are changes to properly reclaim ids so that it avoids infinite loops, but the exact numbers for the ids is highly dependent upon the memory schema of the 4GL process. I hard-coded some numbers in FWD-H2 (like the size of the pages), but these are purely empirical.

From you comment, I understand that ids should be different across different temporary tables. Please check MultiplexedScanIndex.nextOffset - this is a counter to provide the next batch id. Maybe this should be moved at h2.Session level, instead of "per-table".

#9 Updated by Teodor Gorghe 11 months ago

Constantin Asofiei wrote:

Are you saying that if you call CREATE twice one after the other, for different temp-tables, both records will have the same PK in FWD?

Yes.

#10 Updated by Ovidiu Maxiniuc 11 months ago

I am sure this is a regression.

When I implemented the dataset support I would not have been able to identify the images from 4 or more related tables containing the information on same record of the original temp-table. I used the PKs to properly identify which is which and I was melding the outputs from 4GL and FWD which contained the result of ROWID for the aforementioned tables.

In 4GL, each temp-table pre-allocates a series of 0x800 PKs (not remember if this is the correct number) for each temp-table at first use (or maybe at creation/initialisation time). The old implementation was pretty accurate since FWD PKs were really matching those from 4GL (with some rare exceptions, indeed, but they were not a problem). The only adjustment I had to do is set the base record ID since in 4GL it is incremented for each application executed, but in FWD will reset with each server restart. And I had a lot of those.

At any rate, although this is not mandatory a problem as long as the PKs are different 'inside' each table, but some rowid-based queries might fail (return unexpected results) if the 4GL programmer expects the PK to be unique across all temp-tables.

#11 Updated by Teodor Gorghe 11 months ago

Related to Bug #10352: Fix READ-JSON dataset handle method's behaviour added

#12 Updated by Teodor Gorghe 11 months ago

Alexandru Lungu wrote:

There are limitations on how we can assign recid to _temp in FWD. There are changes to properly reclaim ids so that it avoids infinite loops, but the exact numbers for the ids is highly dependent upon the memory schema of the 4GL process. I hard-coded some numbers in FWD-H2 (like the size of the pages), but these are purely empirical.

From you comment, I understand that ids should be different across different temporary tables. Please check MultiplexedScanIndex.nextOffset - this is a counter to provide the next batch id. Maybe this should be moved at h2.Session level, instead of "per-table".

I have some changes for fwd-h2, but I am not really sure if this is right, but the problem is fixed: FWD-H2 patch FWD-H2 patch

=== modified file 'src/main/org/h2/embedded/FWDDirectAccessDriver.java'
--- old/src/main/org/h2/embedded/FWDDirectAccessDriver.java    2025-07-21 13:05:34 +0000
+++ new/src/main/org/h2/embedded/FWDDirectAccessDriver.java    2025-09-04 12:47:43 +0000
@@ -16,10 +16,7 @@
 import org.h2.pagestore.db.MultiplexedScanIndex;
 import org.h2.table.Column;
 import org.h2.table.Table;
-import org.h2.value.ValueLong;
-import org.h2.value.DataType;
-import org.h2.value.Value;
-import org.h2.value.ValueInt;
+import org.h2.value.*;
 import org.h2.result.EmptyResult;
 import org.h2.result.LazySingleResult;
 import org.h2.result.ResultInterface;
@@ -706,6 +703,10 @@
       {
          throw new SQLException("Invalid session");
       }
+      if (session.getVariable("nextOffset").equals(ValueNull.INSTANCE))
+      {
+         session.setVariable("nextOffset", ValueLong.get(0));
+      }

       return session;
    }

=== modified file 'src/main/org/h2/pagestore/db/MultiplexedScanIndex.java'
--- old/src/main/org/h2/pagestore/db/MultiplexedScanIndex.java    2025-09-03 09:56:09 +0000
+++ new/src/main/org/h2/pagestore/db/MultiplexedScanIndex.java    2025-09-04 12:59:55 +0000
@@ -17,6 +17,7 @@
 import org.h2.table.Column;
 import org.h2.table.IndexColumn;
 import org.h2.table.TableFilter;
+import org.h2.value.*;

 /**
  * This is a scan index designed especially for the FWD temp-table. The first column should always be
@@ -79,9 +80,6 @@

    /** The number of rows in this index */
    private long rowCount = 0;
-   
-   /** The offset of next batch we generate */
-   private long nextOffset = 0;

    /**
     * Ids of the batches that should be have been removed during multiplex killing in the current
@@ -114,7 +112,6 @@
       super(table, id, table.getName() + "_DATA", columns, indexType);
       this.tableData = table;
       this.noUndo = noUndo;
-      this.nextOffset = 0;
    }

    /**
@@ -140,7 +137,6 @@
       lastBatches.clear();
       tableData.setRowCount(0);
       rowCount = 0;
-      nextOffset = 0;

       firstBatch = null;
       lastBatch = null;
@@ -171,10 +167,10 @@
    public void add(Session session, Row row)
    {
       long recid = row.getValue(0).getLong();
-      if (!setRow(recid, row))
+      if (!setRow(session, recid, row))
       {
          int multiplex = row.getValue(1).getInt();
-         add(row, multiplex, true); 
+         add(session, row, multiplex, true);
       }
       rowCount++;
    }
@@ -521,7 +517,7 @@
          Batch batch = lastBatches.get((long) multiplex);
          if (batch == null)
          {
-            add(empty, multiplex, false);
+            add(session, empty, multiplex, false);
          }
          else 
          {
@@ -538,7 +534,7 @@

             if (firstBatch == null)
             {
-               add(empty, multiplex, false);
+               add(session, empty, multiplex, false);
             }
             else 
             {
@@ -548,7 +544,7 @@
       }
       else
       {
-         add(empty, multiplex, false);
+         add(session, empty, multiplex, false);
       }

       return empty.getKey();
@@ -567,7 +563,7 @@

       Row empty = session.createRow(null, 1);
       empty.setKey(primaryKey);
-      setRow(primaryKey, empty);
+      setRow(session, primaryKey, empty);

       return true;
    }
@@ -718,7 +714,7 @@
     *          
     * @return  {@code true} if there was a reserved slot waiting for this row.
     */
-   private boolean setRow(long key, Row row)
+   private boolean setRow(Session session, long key, Row row)
    {
       if (key < FIRST_KEY)
       {
@@ -726,6 +722,7 @@
       }
       Long batchId = (key - FIRST_KEY) / BATCH_SIZE;
       int inner = (int) ((key - FIRST_KEY) % BATCH_SIZE);
+      long nextOffset = getNextOffset(session);
       while (batchId >= nextOffset)
       {
          long multiplex = row.getValue(1).getInt();
@@ -734,6 +731,7 @@
          batches.put(nextOffset++, batch);
          lastBatches.put((long) multiplex, batch);
       }
+      setNextOffset(session, nextOffset);
       Batch batch = batches.get(batchId);
       if (batch == null)
       {
@@ -755,14 +753,16 @@
     * @param   forceNewBatch
     *          This should be set on true if we do a bulk insert.
     */
-   private void add(Row row, long multiplex, boolean forceNewBatch)
+   private void add(Session session, Row row, long multiplex, boolean forceNewBatch)
    {
       Batch batch = forceNewBatch ? null : lastBatches.get(multiplex);
       if (batch == null || batch.isFull())
       {
+         long nextOffset = getNextOffset(session);
          batch = new Batch(FIRST_KEY + nextOffset * BATCH_SIZE, this.noUndo, multiplex);
+         setNextOffset(session, nextOffset++);
          notifyNewBatch(batch, multiplex);
-         batches.put(nextOffset++, batch);
+         batches.put(nextOffset, batch);
          lastBatches.put(multiplex, batch);
       }
       batch.add(row);
@@ -846,6 +846,16 @@
       lastBatch = newBatch;
    }

+   private Long getNextOffset(Session session)
+   {
+      return session.getVariable("nextOffset").getLong();
+   }
+
+   private void setNextOffset(Session session, long value)
+   {
+      session.setVariable("nextOffset", ValueLong.get(value));
+   }
+
    /**
     * A batch is just a series of rows whose keys can be reclaimed. The reclaiming is done only for
     * no-undo tables. This is the actual implementation logic behind a single multiplex batch.

I have some questions:
- the current patch might regress something. This code section is multi-threaded? If yes, I should implement just one synchronized function which takes the variable from h2.Session and increments it
- the MultiplexedScanIndex.truncate sets the nextOffset to 0. I think now is no longer required, but I need to think when is called and how often.

#13 Updated by Constantin Asofiei 11 months ago

Lets take a step back. Why do we need in FWD for the recids to be different? What's the minimal standalone test (in a functionally/business logic POV) which requires this?

#14 Updated by Teodor Gorghe 11 months ago

Constantin Asofiei wrote:

Lets take a step back. Why do we need in FWD for the recids to be different? What's the minimal standalone test (in a functionally/business logic POV) which requires this?

Please take a look on #10519-2 PopulateDataset, the expected (4GL) and actual (FWD) WRITE-XML output, described on #10519-6.

#15 Updated by Constantin Asofiei 11 months ago

Teodor Gorghe wrote:

Constantin Asofiei wrote:

Lets take a step back. Why do we need in FWD for the recids to be different? What's the minimal standalone test (in a functionally/business logic POV) which requires this?

Please take a look on #10519-2 PopulateDataset, the expected (4GL) and actual (FWD) WRITE-XML output, described on #10519-6.

Is the problem in READ-XML or WRITE-XML? What is the actual content of the temp-tables (use a FOR EACh) after READ-XML?

#16 Updated by Ovidiu Maxiniuc 11 months ago

The thing that puzzles me is this:

        PARENT-ID-RELATION REL4 FOR node2, commonTable PARENT-ID-FIELD parent_id
        PARENT-ID-RELATION REL5 FOR node11, commonTable PARENT-ID-FIELD parent_id.

In other words, the commonTable table has two parents. This is NOT logical and at the time I implemented the dataset module, I worked with single parent relation in my mind. The only case when these were allowed is when all-but-one of them are disabled. Maybe I got it wrong or maybe this is a special 'feature' of 4GL. Also this might be one of the subtle differences between normal relations (defines with DATA-RELATION) and PARENT-ID-RELATION.

At any rate, if we want this to work as expected, the PKs MUST be unique in FWD as they are in 4GL (this testcase is guaranteed to work correctly only in that case).

#17 Updated by Teodor Gorghe 11 months ago

Constantin Asofiei wrote:

Teodor Gorghe wrote:

Constantin Asofiei wrote:

Lets take a step back. Why do we need in FWD for the recids to be different? What's the minimal standalone test (in a functionally/business logic POV) which requires this?

Please take a look on #10519-2 PopulateDataset, the expected (4GL) and actual (FWD) WRITE-XML output, described on #10519-6.

Is the problem in READ-XML or WRITE-XML? What is the actual content of the temp-tables (use a FOR EACh) after READ-XML?

There was a WRITE-XML problem, which is partially fixed with the current commit on this task branch. The only READ-XML problem (as you know), is the issue addressed by #10352. In order to test with READ-XML, I have took the #10352 fixes.
But the cause of the remaining issue is not by the READ-XML or WRITE-XML. The table contents are attached here here

OE output:

Without READ-XML (populating dataset by "hand")

rootNode
RECID    | name
---------------
8848     | Root

node1
RECID    | name  | rootNode
--------------------------
6440     | node1 | 8848

node11
RECID    | name     | node1
---------------------------
4352     | node11   | 6400
4353     | node11_s | 6400

node2
RECID    | name     | node1
---------------------------
10496    | node2    | 8448

commonTable
RECID    | name     | parent_id
---------------------------
2304     | c1       | 4352
2305     | c2       | 4352
2306     | c3       | 4353
2307     | c4       | 10496

With READ-XML

rootNode
RECID    | name
---------------
2304     | Root

node1
RECID    | name  | rootNode
--------------------------
4352     | node1 | 2304

node11
RECID    | name     | node1
---------------------------
6400     | node11   | 4352
6401     | node11_s | 4352

node2
RECID    | name     | node1
---------------------------
10496    | node2    | 2304

commonTable
RECID    | name     | parent_id
---------------------------
8448     | c1       | 6400
8449     | c2       | 6400
8450     | c3       | 6401
8451     | c4       | 10496

FWD output (without H2 changes)

Without READ-XML (populating dataset by "hand")

rootNode
RECID    | name
---------------
2304     | Root

node1
RECID    | name  | rootNode
--------------------------
2304     | node1 | 2304

node11
RECID    | name     | node1
---------------------------
2304     | node11   | 2304
2305     | node11_s | 2304

node2
RECID    | name     | node1
---------------------------
2304    | node2    | 2304

commonTable
RECID    | name     | parent_id
---------------------------
2304     | c1       | 2304
2305     | c2       | 2304
2306     | c3       | 2305
2307     | c4       | 2304

With READ-XML

rootNode
RECID    | name
---------------
2304     | Root

node1
RECID    | name  | rootNode
--------------------------
2304     | node1 | 2304

node11
RECID    | name     | node1
---------------------------
2304     | node11   | 2304
2305     | node11_s | 2304

node2
RECID    | name     | node1
---------------------------
2304    | node2    | 2304

commonTable
RECID    | name     | parent_id
---------------------------
2304     | c1       | 2304
2305     | c2       | 2304
2306     | c3       | 2305
2307     | c4       | 2304

As you may notice from the testcase, commonTable has 2 parents: node11 and node2, linked by the commonTable.parent_id. When there are two identical RECIDs from two separate tables then the serialized XML or JSON becomes exactly the one described on #10519-6.
I don't think there is a READ-XML or WRITE-XML issue, since the output is different both when the records are populated by "hand" or using READ-XML.
The H2 changes fixes this issue, but I think there is more work to do, to ensure that is thread-safe and there is no regression on NO-UNDO temp-tables.

Ovidiu Maxiniuc wrote:

The thing that puzzles me is this:[...]In other words, the commonTable table has two parents. This is NOT logical and at the time I implemented the dataset module, I worked with single parent relation in my mind. The only case when these were allowed is when all-but-one of them are disabled. Maybe I got it wrong or maybe this is a special 'feature' of 4GL. Also this might be one of the subtle differences between normal relations (defines with DATA-RELATION) and PARENT-ID-RELATION.

At any rate, if we want this to work as expected, the PKs MUST be unique in FWD as they are in 4GL (this testcase is guaranteed to work correctly only in that case).

Exactly

#18 Updated by Constantin Asofiei 11 months ago

commonTable has 2 parents: node11 and node2, linked by the commonTable.parent_id. When there are two identical RECIDs from two separate tables then the serialized XML or JSON becomes exactly the one described on #10519-6.

What is the code which links the child with the parent via recid? Is the parent table there beside the recid?

Otherwise, is the FWD temp-table content the same as 4GL (excluding the recid) after READ-XML?

#19 Updated by Teodor Gorghe 11 months ago

Constantin Asofiei wrote:

What is the code which links the child with the parent via recid? Is the parent table there beside the recid?

Otherwise, is the FWD temp-table content the same as 4GL (excluding the recid) after READ-XML?

For READ-XML, I don't know just yet the exact code location where the record is created and then linked by RECID. I think there is a simple CREATE and fill with data from XML parsing.
For WRITE-XML, the code location is on XmlExport:2791, which just creates a query and executes it. It fetches the parents with the corresponding RECID and there are no issues there.

Constantin Asofiei wrote:

Is the parent table there beside the recid?

Yes, is there after READ-XML.

Constantin Asofiei wrote:

Otherwise, is the FWD temp-table content the same as 4GL (excluding the recid) after READ-XML?

Yes, is the same.

#20 Updated by Teodor Gorghe 11 months ago

Created task branch 10519a_h2 on p2j_repo/h2.

Committed revision 62 on h2 task branch 10519a_h2:
- Moved MultiplexedScanIndex.nextOffset variable to H2.Session.

The H2 changes can be reviewed.
I will change the task status after I fix the indentation issues on WRITE-XML.

#21 Updated by Teodor Gorghe 11 months ago

Status changed from WIP to Review
reviewer Constantin Asofiei added

Committed revision 16147 on task branch 10519a:
- Reverted last commit. Removed hasChild = true on writeChildRecords.

#22 Updated by Teodor Gorghe 11 months ago

% Done changed from 0 to 100

#23 Updated by Constantin Asofiei 10 months ago

Assignee set to Teodor Gorghe
reviewer Alexandru Lungu added

Alexandru - please review 10519a_h2 - it looks good to me.

#24 Updated by Alexandru Lungu 10 months ago

% Done changed from 100 to 90
Status changed from Review to WIP

Review of 10519a_h2:

I don't think while (batchId >= (nextOffset = getAndIncNextOffset(session))) block is required anymore. This was created because you could create a batch, create a row, truncate (so all batches are deleted) and then do a rollback. In the case of rollback, the batch should exist so that the created row is inserted back. We created it incrementally so that nextOffset was iterated from 0 to batchId. If you move nextOffset as a session-level counter, then you can simply disregard this use-case.
- Also, on a long running session, this while loop may iterate a lot, so it is no feasible to still have it in place.
- Still, we need to ensure that batches.get(batchId) doesn't return null. Maybe you can simply create the batch if it doesn't exist:
```
if (batch == null) {
         long multiplex = row.getValue(1).getInt();
         batch = new Batch(FIRST_KEY + batchId * BATCH_SIZE, this.noUndo, multiplex);
         notifyNewBatch(batch, multiplex);
         batches.put(batchId, batch);
         lastBatches.put((long) multiplex, batch);
}
```
No need to synchronize getAndIncNextOffset. H2 sessions are single-threaded by convention.

#25 Updated by Teodor Gorghe 10 months ago

% Done changed from 90 to 100
Status changed from WIP to Review

Committed revision 63 on h2 task branch 10519a_h2:
- Addressed code review #10519-24.

#26 Updated by Constantin Asofiei 10 months ago

Alexandru - do you think is safe to commit 10519a_h2 to fwd-h2 trunk? I need to add this to 9457c.

#27 Updated by Alexandru Lungu 10 months ago

I am OK with 10519a_h2. This can be merged to fwd-h2 trunk.
But I want to stress out this is a high risk change and we need all the testing possible to ensure we did not introduce memory leaks or issues with rollbacks.

#28 Updated by Alexandru Lungu 10 months ago

Status changed from Review to Merge Pending

#29 Updated by Constantin Asofiei 10 months ago

Alexandru Lungu wrote:

I am OK with 10519a_h2. This can be merged to fwd-h2 trunk.
But I want to stress out this is a high risk change and we need all the testing possible to ensure we did not introduce memory leaks or issues with rollbacks.

Understood, I'll merge to fwd-h2 trunk and 9457c.

#30 Updated by Constantin Asofiei 10 months ago

Status changed from Merge Pending to Review

Merged 10519a_h2 to fwd-h2 rev 62 and pushed to projsrv01.

#31 Updated by Constantin Asofiei 10 months ago

Teodor, please fwd-h2 rev 62 in 10519a.

#32 Updated by Teodor Gorghe 10 months ago

Committed revision 16148 on task branch 10519a:
- Upgraded to the latest FWD-H2-1.62.

#33 Updated by Constantin Asofiei 10 months ago

Teodor Gorghe wrote:

Committed revision 16148 on task branch 10519a:
- Upgraded to the latest FWD-H2-1.62.

I've changed to 1.62 in 16149, it was 1.61 in 16148.

#34 Updated by Alexandru Lungu 9 months ago

Anything left to be reviewed?

#35 Updated by Constantin Asofiei 9 months ago

Status changed from Review to Merge Pending

This can be merged after 10509a.

#36 Updated by Teodor Gorghe 9 months ago

Status changed from Merge Pending to Test

Branch 10519a was merged to trunk rev. 16233 and archived.

Also available in: Atom PDF

Project

General

Profile

FWD » Core Development » Base Language

Issues

Custom queries

Bug #10519

ProDataset WRITE-XML issue on nested PARENT-ID-RELATION

History

#2 Updated by Teodor Gorghe 11 months ago

#3 Updated by Teodor Gorghe 11 months ago

#4 Updated by Teodor Gorghe 11 months ago

#5 Updated by Teodor Gorghe 11 months ago

#6 Updated by Teodor Gorghe 11 months ago

#7 Updated by Constantin Asofiei 11 months ago

#8 Updated by Alexandru Lungu 11 months ago

#9 Updated by Teodor Gorghe 11 months ago

#10 Updated by Ovidiu Maxiniuc 11 months ago

#11 Updated by Teodor Gorghe 11 months ago

#12 Updated by Teodor Gorghe 11 months ago

#13 Updated by Constantin Asofiei 11 months ago

#14 Updated by Teodor Gorghe 11 months ago

#15 Updated by Constantin Asofiei 11 months ago

#16 Updated by Ovidiu Maxiniuc 11 months ago

#17 Updated by Teodor Gorghe 11 months ago

#18 Updated by Constantin Asofiei 11 months ago

#19 Updated by Teodor Gorghe 11 months ago

#20 Updated by Teodor Gorghe 11 months ago

#21 Updated by Teodor Gorghe 11 months ago

#22 Updated by Teodor Gorghe 11 months ago

#23 Updated by Constantin Asofiei 10 months ago

#24 Updated by Alexandru Lungu 10 months ago

#25 Updated by Teodor Gorghe 10 months ago

#26 Updated by Constantin Asofiei 10 months ago

#27 Updated by Alexandru Lungu 10 months ago

#28 Updated by Alexandru Lungu 10 months ago

#29 Updated by Constantin Asofiei 10 months ago

#30 Updated by Constantin Asofiei 10 months ago

#31 Updated by Constantin Asofiei 10 months ago

#32 Updated by Teodor Gorghe 10 months ago

#33 Updated by Constantin Asofiei 10 months ago

#34 Updated by Alexandru Lungu 9 months ago

#35 Updated by Constantin Asofiei 9 months ago

#36 Updated by Teodor Gorghe 9 months ago