[fpc-pascal] TSortedCollection dupes ordering

waldo kitty wkitty42 at windstream.net
Thu Feb 6 00:24:10 CET 2014


On 2/5/2014 3:57 AM, Frederic Da Vitoria wrote:
[...]
> Once again I did not test this, but it seems to me that if Compare returned -1
> instead of 0, any duplicate would be inserted after because it would never be
> considered as equal to any other. But since you still want your collection to be
> able to choose between skipping duplicates or keeping them, the Compare
> modification would have to be slightly more subtle, something like:
>
> if result = 0 and Duplicates
>      then result := -1
>
> at the end of the Compare function.

i tried this and it kinda works... it keeps the entries in their original order 
but...

1. the final logging of each item's "record number" (position in the collection) 
is -1
2. it doesn't help to sort them in order by a different field

i'm unsure what to do or how to handle this so that there is a secondary (sub) 
sorting order so that the main key is the master sort and then a secondary 
""key"" is used when duplicates are allowed... ideally, the secondary key would 
retain the original order in the case that the ""secondary key"" is exactly the 
same as a previous ""secondary key""... but this is also problematic...

to try to clarify: sometimes there are records released with exactly the same 
time stamp (epoch in my code i posted) but slightly different data within the 
record... there is another field that might be used to differentiate those BUT 
the records come from numerous locations... they may or may not use this 
""tertiary key" and if they do, their numbering in this ""tertiary key"" may not 
be the same as any other system's count for this ""tertiary key""... this is a 
problem i don't know how to solve as there is no coordination between locations 
and no ""master"" coordinator for this ""tertiary key""... it becomes even more 
apparent because my flow doesn't take any certain record containers before any 
others... they are read and processed as they appear (OS ordering actually) 
which may cause ""newer"" records with an identical time stamp to be processed 
after others... in my current design, i'm using "first come, first served" 
meaning that the first record processed is the one that is retained... with 
dupes, this doesn't matter so much but it does all still come into play...

-- 
NOTE: No off-list assistance is given without prior approval.
       Please keep mailing list traffic on the list unless
       private contact is specifically requested and granted.



More information about the fpc-pascal mailing list