Zugg Software :: View topic - 3.22 database variable sorting and %iskey

Apprentice Joined: 15 Jun 2010 Posts: 121

I hope this is not a duplicate bug, the only related post is due to the case sensitive option (which is a separate bug I believe...), but I believe this is pretty thorough:

There appears to be two or three bugs relating to unsorted database variables:
(1) inconsistency with json, which might be root of the bugs...:

#show %json(@dbvar) - shows dbvar, with option sort=none, erroneously sorted reverse alphabetical (note: shows correct order if the sort option is set to something other than 'none')
#show @dbvar - shows dbvar, with option sort=none, correctly unsorted

(2) in the package editor, if you change the sort option of a database variable from none, to something else, than back to none, it will actually sort the data in reverse alphabetical sort even though it is set to none: i.e. both #show %json(@dbvar) and #show @dbvar and package editor show sorted as such

(2b) After case(2), it get's stuck in reverse alphabetical order like this, ie if you add a key to the variable using #ADDKEY it will add it in its (incorrect) reverse alphabetical position as opposed to its (correct) unsorted position, which should be as the last keynum.

(3) %iskey not working as expected with unsorted variables, it the returns key number as the nth key in #show %json(@dbvar) (the incorrect reverse alphabetical order)
Compare this to %db(@dbvar,keynumber) returns value based off of nth key in #show @dbvar (the correct unsorted order)

I believe the equivalent of %iskey should be: %ismember(keyname,%dbkeys(dbvar))
However this is not always the case as with case (1)

Note: I initially found these problems when debugging when I discovered that in some cases %iskey(@dvbar,keyname) was not equivalent to %ismember(keyname,%dbkeys(dbvar))
I.e.: like with case (1), I already had the name of a key, and wanted the value of the next key in the database variable (wherein #loopdb wasn't really appropriate), and did something (unsuccessfully) to the effect of:
%db(@dbvar, (%iskey(@dbvar,keyname) + 1))

Now here are some examples that highlight the inconsistency :

Examples:

1) create a database variable tmptmp with some unsorted keynames using the command line:

Posted: Fri Jul 23, 2010 5:31 pm

I'll take a closer look at this when I'm back next week.

However, here is some additional information on this.

JSON does not store the original order of the items. The output of %json comes from the low-level JSON routines and shows the order of items according to it's internal hash table. When the table is sorted, the %json should properly show the sorted result. But once a table has been sorted, there is no way to "put it back" into unsorted order because JSON itself doesn't keep track of that information.

In CMUD, I added an additional array to each hash table that allows me to keep track of the original order of the items. But this only works with the %item and @db.1 functions. If you sort the table and then close CMUD and reopen it and then try to unsort the table, CMUD will have lost the original item order so it won't work.

I have tried a lot of tricks to get the database variables to show their original sort order, but it just isn't really possible to do this completely when using hash tables. You just really cannot depend upon the order of items in an unsorted database variable.

As I said, this is just general information. I haven't actually been able to try any of your examples yet from here, but will look at this again next week and post any additional information that I learn.