cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <mgen...@masslight.net>
Subject Ashwood Issues
Date Fri, 22 Jul 2011 12:47:59 GMT
This message will be a little dense ... just warning up front.  :-)

We've had two main issues with AshwoodEntitySorter (and, I believe,
Ashwood) that have produced "Can't extract a master key" and "Cycles
found" errors.


1) Can't extract a master key ...

My guess is this stems from a glitch in IndegreeTopologicalSort.  In
3.0, I modified _indexSorter() to have the following logging:


components = new HashMap(contractedReferentialDigraph.order());
int componentIndex = 0;
while (sorter.hasNext()) {
    Collection component = (Collection) sorter.next();
    log.info("looping over component");
    ComponentRecord rec = new ComponentRecord(componentIndex++, component);
    log.info("Creating new component record[" + componentIndex + "]: "
+ component);
    for (Iterator i = component.iterator(); i.hasNext();) {
        log.info("Adding {" + next + "," + rec + "}");
        components.put(i.next(), rec);
    }
}

This would produce logs like:


Creating new component record[57]: [proc_mod_item_install_cost]
looping over component
Adding {proc_mod_item_install_cost,index: 57; componet:
[proc_mod_item_install_cost]}
Creating new component record[58]: [proc_advance_bdgt_just]
looping over component
Adding {proc_advance_bdgt_just,index: 58; componet: [proc_advance_bdgt_just]}
Creating new component record[59]: [proc_rqmts_sched,
proc_bdgt_qtrs_data, proc_rqmts_sched_install_EIF,
proc_rqmts_sched_install_agent, proc_cost_element,
proc_history_and_planning, proc_manufacturer]
looping over component
Adding {proc_rqmts_sched,index: 59; componet: [proc_rqmts_sched,
proc_bdgt_qtrs_data, proc_rqmts_sched_install_EIF,
proc_rqmts_sched_install_agent, proc_cost_element,
proc_history_and_planning, proc_manufacturer]}
Adding {proc_bdgt_qtrs_data,index: 59; componet: [proc_rqmts_sched,
proc_bdgt_qtrs_data, proc_rqmts_sched_install_EIF,
proc_rqmts_sched_install_agent, proc_cost_element,
proc_history_and_planning, proc_manufacturer]}
Adding {proc_rqmts_sched_install_EIF,index: 59; componet:
[proc_rqmts_sched, proc_bdgt_qtrs_data, proc_rqmts_sched_install_EIF,
proc_rqmts_sched_install_agent, proc_cost_element,
proc_history_and_planning, proc_manufacturer]}
Adding {proc_rqmts_sched_install_agent,index: 59; componet:
[proc_rqmts_sched, proc_bdgt_qtrs_data, proc_rqmts_sched_install_EIF,
proc_rqmts_sched_install_agent, proc_cost_element,
proc_history_and_planning, proc_manufacturer]}
Adding {proc_cost_element,index: 59; componet: [proc_rqmts_sched,
proc_bdgt_qtrs_data, proc_rqmts_sched_install_EIF,
proc_rqmts_sched_install_agent, proc_cost_element,
proc_history_and_planning, proc_manufacturer]}
Adding {proc_history_and_planning,index: 59; componet:
[proc_rqmts_sched, proc_bdgt_qtrs_data, proc_rqmts_sched_install_EIF,
proc_rqmts_sched_install_agent, proc_cost_element,
proc_history_and_planning, proc_manufacturer]}
Adding {proc_manufacturer,index: 59; componet: [proc_rqmts_sched,
proc_bdgt_qtrs_data, proc_rqmts_sched_install_EIF,
proc_rqmts_sched_install_agent, proc_cost_element,
proc_history_and_planning, proc_manufacturer]}
Creating new component record[60]: [proc_ifp_funding]
looping over component
Adding {proc_ifp_funding,index: 60; componet: [proc_ifp_funding]}
Creating new component record[61]: [proc_pfp_related_proj]
looping over component
Adding {proc_pfp_related_proj,index: 61; componet: [proc_pfp_related_proj]}
Creating new component record[62]: [proc_compo_split]


The sorted order from IndegreeTopologicalSort would end up with
duplicates (#59 in this case).  The output was 1..58, then duplicates
for 59, then 60..end.  This later caused the TableComparator to fail
because the index in ComponentRecord was 59 and when it compared
proc_history_and_planning to proc_manufacturer, they were both 59
which returned 0 (equal to each other).  Our proc_manufacturer has to
be inserted before proc_history_and_planning, so this caused the
"Can't extract a master key" error because proc_manufacturer was after
proc_history_and_planning even though they both had the same weight of
59.

I later modified the code to be:


IndegreeTopologicalSort sorter = new
IndegreeTopologicalSort(contractedReferentialDigraph);
components = new HashMap(contractedReferentialDigraph.order());
int componentIndex = 0;
log.info("AshwoodEntitySorter._indexSorter: looping over
IndegreeTopologicalSort digraph");
while (sorter.hasNext()) {
    Collection component = (Collection) sorter.next();
    log.info("AshwoodEntitySorter._indexSorter: looping over component");
    for (Iterator i = component.iterator(); i.hasNext();) {
        log.info("AshwoodEntitySorter._indexSorter: Creating new
component record[" + componentIndex + "]: " + component);
        ComponentRecord rec = new ComponentRecord(componentIndex++, component);
        Object next = i.next();
        log.info("AshwoodEntitySorter._indexSorter: Adding {" + next +
"," + rec + "}");
        components.put(next, rec);
    }
}


I moved the componentIndex++ to be in the loop.  This at least had the
advantage of no more duplicates (no repeated 59s), but the sort order
was still incorrect out of IndegreeTopologicalSort and the inserts
still failed.  Although we seem to be alleviating this issues a bit
with @SortWeight, it appears the weighting is causing trickle-down
problems because we then have to go change the weighting of other
classes.


2) Cycles found ...

sortObjectsForEntity() appears to have issues if you override equals()
on Data Objects that are reflexive.  If we comment out the
equals/hashcode that were added on the reflexive object, it works, if
we put it back, it fails.  I haven't explored this one in depth, but
it appears that it is looking for identity and not equivalence on
reflexive relationships.


At this point, I'm considering re-writing AshwoodEntitySorter.  At
least with 3.1 I can give it a different name and use the DI to patch
it for testing.  :-)

mrg

Mime
View raw message