Issues with data deploy in heavily nested replicants

rashy

Hi,

I have a DCT with a 4 level nested replicants. When I try to do a data deployment, it behaves inconsistently.

For small DCR's the deployments complete successfully most of the times( hung otherwise).
But in case of a slightly larger DCR, the deployments get hung most of the times (successful otherwise) and the logs does not show anything either.

I have also tried running an iwsyncdb rowmapgen for this. But that finishes without a generated row-map, stating "no group contains mapping for nested replicants".

The JVM heap size was also increased inside the processod file.

Is there any limit on the levels of nesting replicants in a DCT.
Or is there any other way to improve the performance?

TS 6.7.2
OD 6.2.1

-Rasheed

Rick Poulin

I personally try to avoid nested replicants (esp. 4 levels of them) because it tends to cause problems like this. I'd hate to see what your rendered form looks like. If it's still early in your dev phase, I'd suggest structuring your form differently.

Be that as it may, has your deployment always locked up or is this a new occurrence?
* New thing: implies memory/sizing issues. 4 levels of replicants implies that you have a LOT of DB rows being tracked at once including parent-child dependencies.
* Otherwise: if your DD config has never worked properly, that could be due to a whole whack of things, notably the fact that the queries produced by DD aren't exactly pretty and they may overflow the SQL query buffer provided by your DB vendor. Could also be that there's other connectivity problems -- try a very simple one-table deployment first to make sure it's your nested structure that's the issue.

If your forms structure has to remain the same, then I'd recommend introducing some pre-processing into your workflow to flatten your record into a more useful XML structure, and then deploy that. E.g. where you might have had

<parent>
  <id>123</id>
  <!-- ... other data points on parent ... -->
  <children>
    <child>
      <id>456</>
      <!-- ... other data points on child ... -->
    </child>
    <!-- ... other child nodes ... -->
  </children>
</parent>

pre-process-convert that to

<root>
  <parent>
    <id>123</id>
    <!-- ... other data points on parent ... -->
  </parent>
  <children>
    <child>
      <id>456</id>
      <parent-id>123</parent-id>
      <!-- ... other data points on child ... -->
    </child>
    <!-- ... other child nodes ... -->
  </children>
</root>

If you extrapolate this structure, you'll find that you're basically reducing any hierarchy to a single replicant instance, with different DD <group> elements that can be part of the same deployment but don't map to each other (as far as DD is concerned) using an explicit foreign key mapping.