when a newly-created aggregate submits data for the first time, the resource's aggregate field is unset in the database

[chaos@bbn.com]

When a new dataset is submitted containing:

• a new aggregate entity
• new resources associated with that aggregate

the resources are created by xchange2db before the aggregate is created, so the aggregate_id for each resource must be left NULL.

When the data is updated on a subsequent submission, the aggregate_id is corrected for each resource which still exists.

[chaos@bbn.com]

This is hard to fix because of the circular connections:

• When xchange2db processes an aggregate, it processes that aggregate's slivers and each sliver's sliver mappings as part of that <aggregate> block. If the resource doesn't exist yet when that gets done, we get a much more serious error in which submission fails altogether.
• When xchange2db processes a resource, it links to the aggregate if the aggregate it's given already exists, and not otherwise.

One way to fix this, in principle, would be to process submissions in the order:

1. aggregate
2. resources
3. slivers
4. resource mappings

However, my assumption is that we can't do that because the structure of the XML is that a <sliver> is part of an <aggregate>, but a <resource> isn't (because it's possible for a resource not to be part of an aggregate). So that means there's no clean way to process the XML in the order i suggested.

The impact of this on production data is very very low --- it's going to be very rare that an aggregate will submit its resources, and never follow up to resubmit those resources. TMF resubmits relations every five minutes, and that's the standard we suggest to other people. However, it's messy, so we wanted to make a ticket.