Re: [Glorp-development] [BUG] row sorting

[Alan K. <kn...@ac...>]

OK, got to take a look at this.

Yes, the test in rowsRelatedTo: for table equality rather than testing the 
field was clearly wrong, and your solution looks good, although I changed 
it some because of the other issues.

The complete 3-graph cycle example did break the sorter. It appears that a 
way around this is, if the queue is empty and there are no non-visited 
nodes, go back and make another pass looking for once-visited nodes. This 
appears to fix the problem. It results in a fairly arbitrary order in those 
cases, but that's what happens with cycles.

The code was also definitely slow in searching containedBy. No one was 
actually using the dictionary property of containedBy, it was always 
iterated over, so I switched it from being a dictionary from rows to a list 
of fields and made it from fields to a list of rows. This makes it possible 
to more quickly get the related rows, although it's still necessary to loop 
over them, but at least only the ones that are actually related. I also 
changed the row sorter to cache the collection of children, since we were 
asking for that repeatedly during the sort. A customer with 10000 
transactions now takes about 20 seconds to write on my machine, and one 
with 5000 about 10 seconds, so it seems fairly linear. Along the way I also 
discovered a very non-linear operation in embedded values and fixed that.

Published as 0.3.56


At 03:58 PM 3/28/2004, Andre Tibben wrote:
>There is a bug in the sorting of rows. When a foreign key points to the
>same table ForeignKeyConstraint>rowsRelatedTo: can give the wrong rows.
>Attached are a testcase that shows the problem and a possible solution.
>The use of 'targetFields first' in the solution is dependent on the
>implementation of someSourceField being 'sourceFields first'.
>
>A related problem is that if there are cycles in related rows the output
>of GlorpRowSorter can contain less elements than the input. This is
>shown in the third attachement. The problem above can trigger this
>easily.
>
>A third problem is that the code is quadratic in the size of the
>containedBy ivar. A timeprofile shows that for inserting a GlorpCustomer
>with 10000 GlorpBankTransaction 75% of the smalltalk time is spent
>sorting.
>
>Andre Tibben
>
>Content-Description:
>Content-Disposition: attachment; filename=glorp-related-rows.st
>Content-Type: text/xml; charset=
>
>Content-Description:
>Content-Disposition: attachment; 
>filename=ForeignKeyConstraint-rowsRelatedTo.st
>Content-Type: text/xml; charset=
>
>Content-Disposition: attachment; filename=glorp-rowsorter-test.st
>Content-Type: text/xml; name=glorp-rowsorter-test.st; charset=

--
Alan Knight [|], Cincom Smalltalk Development
kn...@ac...
ak...@ci...
http://www.cincom.com/smalltalk

"I believe that many of the systems we build today in Java would be better 
built in Smalltalk and Gemstone." -- Martin Fowler, JAOO 2003