Zugg Software :: Stringlists / Tables

In past 2.x versions of CMUD, string lists and database variables (tables) could be used to store some structured data, but their use was limited. You could create a simple string list, such as:

list = {item1|item2|item3}

or you could create a simple database variable such as:

db = {name=Zugg|level=20}

but if you tried to mix these two, such as placing a string list within a database variable, all sorts of problems would emerge. Even when it worked, CMUD v2 could not use it's internal hashing to speed up a string list that was stored within a database variable, resulting in slow operations.

In v3, the string list and database variable code has been rewritten to allow any level of nesting and to have high performance at all times. String lists and tables are stored internally as JSON data structures, similar to the data structures used in Lua and Javascript.

Nesting arrays and tables

The proper method for nesting an array within a table (or vise-versa) is the same as it was in v2. Using the above two variables, you could add the @list string list to the database variable using the #ADDKEY command:

#ADDKEY db list @list

Now if you access @db.list you will get the {item1|item2|item3} list. While this seemed to work in v2, it was really only returning the actual *string* value of "{item1|item2|item3}". v2 did not allow you to query an item within this list directly. In v3, the actual string list structure is returned, allowing you to access the list items directly with this simple syntax:

#SHOW @db.list.2

to display "item2", which is the second item in the list. This "dot notation" can be used to access any part of a nested table or array to any levels deep. And high performance caching it used at each level for maximum speed.

String formats

If you use the existing list commands and functions, such as #ADDITEM, #ADDKEY, etc, then you will have no problem using these new enhancements in your script. However, if you are relying upon the "string format" of a list or database variable, then you might have problems.

For example, some people create a string list using %concat to form the string, such as:

list = %concat("{","item1","|","item2","}")

or variations of the above syntax. Using %concat in this way will create @list as a string variable and not as a stringlist. You can convert a string variable to a proper list using the new %list function. CMUD will also attempt to handle the string variable properly, such as when accessing an element like @list.2. But because CMUD must internally convert the string value to a list this is much less efficient than creating a proper string list in the first place. Needless conversions between string format and internal json format will be the biggest causes of slow scripts.

So be sure to convert your scripts to remove any dependence upon the actual string format of the list or table. Use the provided commands and functions to add items to the list, or change items in a list, or delete items, etc.

Raw JSON data

You can convert a string list or database variable into a JSON string format using the new %json function. Normally this function is for debugging purposes. The JSON string format is also displayed when you use the #VAR command to dump the variable, or when you export the variable to XML.

If you are using a web-related script to retrieve data from a web service in JSON format, you can convert that json string value into a proper list or table also using the %json function.

For backwards compatibility, but the JSON string format and the original CMUD stringlist or database variable string format is saved in your package and exported via XML. This allows your package file to still be read by the older v2 CMUD. In the future when fewer people are still using v2, this option will be removed so only JSON data will be stored in your package. In the meantime, if you have very large lists or tables, your data will be doubled in the package. If you don't plan to use CMUD v2 anymore, you can turn off this compatibility option in your Scripting Preferences "Output compatible string lists" option.

Performance

The new list/table format is very efficient, even compared to the hashing algorithm used in CMUD v2. Here are some benchmark comparisons. Click Here to see the actual test scripts.

CMUD v3