Hello,
I like to see the most interesting ( == commented) games to replay at the top
of the gamelist window when the tree filter is enabled. I cannot sort the
columns, but now I can sort the database. This comes in handy.
The first alternative is a bit tricky. It sorts the indes, which is always in
memory. When the database is closed the index is saved. So the original order
gets lost and the games in the game file are no longer sequential, but it is
very easy to implement.
The second more serious alternative is not really a filter. It is something
like a transposition table, four bytes needed for each game in the base. The
game list window has only few interface methods and it is not so difficult to
adapt them. Waiting five seconds for a reordering sounds accepable, because you
do it only once and not with each call.
Gerd
----- Ursprüngliche Nachricht -----
Von: Steven
Gesendet: 22.02.11 08:00 Uhr
An: Gerd Lorscheid
Betreff: Re: [Scid-users] Sorting by variations patch
>The appended small 12-line patch allows to sort bases also by variation count
>and comment count from the maintenance window.
Seems to work here. On the surface it sounds like one of
those useless features, but i'm *sure* it will come in very handy.
>I remember a discussion whether to allow column sorting in the game list
>window.
>
>When sorting a base it is now done in three steps. In the first the index is
>resorted and in the second the games are updated and written to the disc. The
>first two are done when sorting is called in the maintenance window. The first
>step takes for 5.000.000 games around 5 seconds. The second writes the index.
>As
>
>a third step a user should compact the game file to enforce its recreation.
>Otherwise any search over all games will be slow, because subsequent games are
>not in the same game block.
>So sorting columns would have a reasonable performance and can be implemented
>in
>
>two ways:
>The first try is simply to reuse this first step above but not making it
>persistent.
Hmmm . I suppose you mean sorting the DB but not writing it to disk.
Are you sure this is feasible ? I'm not overly familiar with
DB structure and searches, but it sounds dangerous to me
considering Scid's complexity. And at least part of Scid's
stability comes from it's immediate write-to-disk policy imho.
> The problem in large bases then is that searching will be slow,
>because the games are distributed randomly in the game file.
>The second solution would be to add a mapping filter as soon as a user sorts
>games in the gamelist window. The advantage is that this is invisible to the
>search algorithms. The price is that it will cost around 20 MB memory for a
>5.000.000 database.
More filters !... [runs screaming from room].
>But I am not sure whether sorting is really necessary. I would use it only to
>get commented and top-rated games to the top of the list, but this I get also
>by
>
>sorting the base after each import of new games.
>
> Gerd
Steven
------------------------------------------------------------------------------
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk
Collect, index and harness all the fast moving IT data generated by your
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights.
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
