 |
Anaristos
Sorcerer
Joined: 17 Jul 2007
Posts: 821
Location: California
|
 Posted: Fri Jun 06, 2008 6:18 am
Behavior of db variables residing in stringlists
|
Assuming I have variable $list populated with a list of db variables which are identical in structure, I've found that doing $data = %db($list,dbvalue) will return the last entry in the list and not the first. In other words, %db treats the stringlist as a([n] inverted) stack and not a queue. However, when the variables are inserted into the list, the go in FIFO. This seems counter-intuitive to me and perhaps a bug.
|
|
_________________
Sic itur ad astra. |
 |
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Fri Jun 06, 2008 2:48 pm
|
What do you mean by "a list of db variables" - either your $list variable is a string list, and you shouldn't be using %db on it - you presumably want %db(@{%item($list,n)},key) - or it's a db variable, in which case I'm not sure what you're talking about orders for.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Jun 06, 2008 5:34 pm
|
Fang is correct that your terminology is confusing. %db only works on database variables, but maybe that is what you are talking about. Database variables are stored as a hash table, and the "order" of these items is undefined. They are not implemented as simple stacks or queues.
|
|
|
|
|
Anaristos
Sorcerer
Joined: 17 Jul 2007
Posts: 821
Location: California
|
Posted: Sat Jun 07, 2008 12:09 am
|
I understand that. But IMO that only applies to how the values are stored within the variables. What I am referring to is how db variables are accessed when stored in a string list. The string list doesn't know it contains db variables. All it knows is that it has a series of strings separated by some defined separator character. So when I refer to an entry in the list by %item(listname,itemindex), it counts separators until it reaches the (index)th one and it returns the string delimited by the (index)th and (index-1)th separator.
What I am saying that it is happening is that if instead of doing
| Code: |
$item = %db(%item($list,1),value)
|
to explicitly retrieve the value in the first entry of the list I do
| Code: |
$item = %db($list,value)
|
it will retrieve the value for the last db variable stored in the list.
So if I have
| Code: |
$list = key1value1|key2value2|key3value3
|
then the second type of access will return value3, not value1 as one would intuitively expect. Now, if random values were returned because of the lack of indexing, that would make more sense. Instead, it always returns the last entry so I must assume that it is purposely seeking that key/value pair.
There are other instances when item retrieval is not explicitly stated and in these instances it will return the first item.
All this means that while stringlists are really nothing but strings and can be manipulated as such, internally, the code is aware that it is a stringlist, either because the variable was explicitly defined as such, or some stringlist operation was performed on the variable. This supports the conclusion of forced last entry retreival by the %db function.
My point being that if it is intentional, then it is counter-intuitive, and if it is not, then it is a bug. |
|
_________________
Sic itur ad astra. |
|
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Sat Jun 07, 2008 7:41 am
|
I still have no idea what you're on about. I think you need to begin by describing exactly what kind of data structure you're storing in this variable - how you set it up, what it looks like, and how you want to access it. Stop using pseudocode and start using your real code, at least the lines of it that create and access this variable.
You start off by talking about "db variables stored in a string list", which makes me think you mean you're doing some kind of weird multi-layered thing like:
| Code: |
var(stringlist)
item1(dbvariable)
item1-key1 - item1-val1
item1-key2 - item1-val1
item2(dbvariable)
item2-key1 - item2val2 |
But that clearly isn't going to work. So my second guess is that you have a stringlist that contains a bunch of names of dbvars, for which you're going to need what I showed you before, %db(@{%item($list,n)},key). But then finally, at the end, you show us some supposed contents of $list, and all it is is a stringlist. It's got keys and values, but they're not formatted properly to be a dbvar.
So, please, explain what you're doing first :( |
|
|
|
|
Zhiroc
Adept
Joined: 04 Feb 2005
Posts: 246
|
Posted: Sat Jun 07, 2008 2:40 pm
|
It sounds to me like if you do:
| Code: |
#VAR v1 {a=b|c=d}
#VAR v2 {e=f|g=h}
#VAR st {@v1|@v2} |
you expect to have a stringlist containing two DB vars? You don't. You have one DB var containing all the records from the two original ones.
Which record you get if you have repeated keys is probably undefined. (It should be an error to save a DB var with repeated keys, IMHO. Or it should redefine keys, later definitions overriding earlier ones).
If this isn't what you meant, then you'll have to explain further. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Jun 09, 2008 5:28 pm
|
Having a database variable within an element of a *STRING* List is not supported. A String List contains a list of "strings". If you try to put a database variable into an element of a string list, then CMUD is just going to treat the database variable as a regular string value and you will lose all of the hash-table speed optimizations in CMUD.
When using %item or %db, CMUD isn't simply "counting delimiters". The %db function is made to work with database variable hash tables, and the %item function is made to work with hashed string tables. You cannot just pass the string list to the %db function.
| Quote: |
| All this means that while stringlists are really nothing but strings and can be manipulated as such, internally, the code is aware that it is a stringlist |
Yes, that is true. That is how CMUD is able to optimize the speed of string lists and database variables. In old versions of CMUD, and in zMUD, a "string list" was just a string. But in newer versions of CMUD, a string list is implemented differently internally (as a hashed table) and you just normally see the string "value" of the string list. Same with database variables.
If you want to manipulate these types of variables as strings, you should explicitly convert them to strings using the %string function. For example, %string(@dbvar) will convert a database variable into a normal string value that you can manipulate.
Otherwise, yes, functions like %db and %item now operate on the internal hashed structure and not on the string value itself. That is how the newer version achieve *huge* speed improvements with string lists and database variables. |
|
|
|
|
Anaristos
Sorcerer
Joined: 17 Jul 2007
Posts: 821
Location: California
|
Posted: Tue Jun 10, 2008 12:50 am
|
I understand now what you mean, Zugg. I do have a hugh stringlist which contains elements that appear to be database variables (they were database variables when I did the %additem) and when used in conjunction with the %item function, behave as such. I assume this is because once the item is extracted from the list, and the %db function is applied to it, the auto-typing kicks in and the function successfully retrieves the value. Thanks for your explanation.
|
|
_________________
Sic itur ad astra. |
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
