--- "David E. Jones" <[EMAIL PROTECTED]> wrote: > > Yeah, there are various loops: self-referencing entities (A -> A) and > mulit-entity loops (A->B->A; A->B->C->A; etc). > -David >
So, I went ahead and wrote a script to walk and order the entities and it turns out there are only two loops which are actually more like kinks (granted it takes 17 passes to reduce the relationships to these two loops, but it does get there ). Knowing the order of entering entity data that won't fail and need to be retried on subsequent passes will more than make up for the three minutes of processing time it takes to determine. These should be identifiable by A-B = B-A. The A->B->C->A loops and greater would obviously be difficult to identify, but it doesn't currently exist in OFBiz, so I'll assume that it's theoretical and not likely to exist in a highly normalized generic data model. You have the self-referencing entities (A=A) which you can avoid referential integrity issues by walking the record hierarchy of that entity parent->child. These are easily identified by having both the entity and rel-entity equal to one another. The two restricting loops are both A->B->A 1. UserLogin->Party->UserLogin This is caused by a denormalized(non-normalized) field Party.createdBy and the application specific field UserLogin.partyId. 2. FinAccountTrans->Payment->FinAccountTrans I haven't looked at the application logic, but it appears by looking at the data model that either FinAccountTrans.paymentId or Payment.finAccountTransId is redundant. Judging by the rest of FinAccountTrans, I would say that the paymentId is the one misplaced as there is much denormalized information. I wouldn't suspect that this is a heavily read area of the data model that requires denormalization. #1 can be addressed by ordering the records or by treating as a graph whereby creating a two column temporary join table (A__B ie UserLogin__Party) hold the referential data, set the fK to null, load all the records, then run an update from the temporary table to the original entity. #2 can be probably be addressed by fixing the logic as there are likely 1:1 relationships between the records and therefore a misplaced fk.
