Hi Jakob
On Thu, 18 Nov 2004 21:17:04 +0100, Jakob Braeuchi [EMAIL PROTECTED] wrote:
hi gerhard,
i applied a small fix in addCollectionEdges()
...
else
{
if (col instanceof ManageableCollection)
{
Collection newCol = new ArrayList();
Hi Jakob,
On Fri, 19 Nov 2004 08:20:53 +0100 (MET), Jakob Braeuchi [EMAIL PROTECTED]
wrote:
hi armin,
in the testcase i mentioned the auto-update is set to LINK.
does the scenario you describe also work for odmg ? i was thinking of
something similar in PB: the PB keeps track of the
Hi Jakob,
Jakob Braeuchi wrote:
hi armin,
in the testcase i mentioned the auto-update is set to LINK.
does the scenario you describe also work for odmg ?
suggestion only made for odmg
i was thinking of
something similar in PB: the PB keeps track of the mn-implementors to be
inserted and inserts
Hi,
for quite some time we were experiencing problems with FK constraint violations
when committing ODMG transactions. We resolved these problems by inserting
TransactionExt.flush() calls wherever necessary. However, this in turn produced
deadlock problems under high server load. Therefore we
Dnia czwartek, 18 listopada 2004 14:54, Gerhard Grosse napisa:
Hi,
...
The ObjectEnvelopeOrdering class uses a graph-theoretical approach to order
the
object envelopes (see the JavaDoc for details). Edges in this graph are
inserted
only if there really is a need for ordering two object
hi gerhard,
thanks for your contribution. it looks really impressive !
i integrated your class into to current 1.0.x branch an ran all odmg testcases
without skipping known issues.
with the old reorder i get:
Tests run: 207, Failures: 2, Errors: 8
with your ordering i still have 6 errors:
hi gerhard,
i applied a small fix in addCollectionEdges()
...
else
{
if (col instanceof ManageableCollection)
{
Collection newCol = new ArrayList();
CollectionUtils.addAll(newCol, ((ManageableCollection)
col).ojbIterator());
hi gerhard,
the failing testcases in org.apache.ojb.odmg.M2NTest can not at all be fixed by
reordering.
the problem is the bidirectional m:n relationship with auto-update = LINK on
both sides. no matter what side is inserted first pb tries to insert into the
indirection-table as well. this
Jakob Braeuchi wrote:
hi gerhard,
the failing testcases in org.apache.ojb.odmg.M2NTest can not at all be
fixed by reordering.
the problem is the bidirectional m:n relationship with auto-update =
LINK on both sides. no matter what side is inserted first pb tries to
insert into the
hi armin,
in the testcase i mentioned the auto-update is set to LINK.
does the scenario you describe also work for odmg ? i was thinking of
something similar in PB: the PB keeps track of the mn-implementors to be
inserted and inserts them when the main objects are in the tables.
gerhards new
10 matches
Mail list logo
