Using Lists as a Database

Hi guys,

I have seen the various threads asking about writing data to a notecard (can't be done) and about writing to external databases via HTTP, or clever methods of storing data in description fields of prims etc.

Can anyone tell me, in simple terms, why you cannot just read and write data to/from a list variable, and create a new list variable when one gets full?

If I store data in a list variable, then take the prim containing the script into inventory, then rerezz it, will the data in the list variable survive?

And if a region restarts, will list data survive?

Rock

You can do that and the data should survive. Lots of objects do just that.
Its still a little awkward: you cant really just create a "new list variable"automatically when one gets full though. You'd have to have another prim or script show up and take over the load.

Also if you have to reset the script for some reason, the list will be reset to [] and your data will disappear.

And the maximum heap space is 16kB which was a lot of memory in 1980.

Exactly, except if you think about it there is a way to do it automatically and it will keep doing the same trick, as needed, on and on. Think "spawn" for memory.

once you give permissions to a rezzed object that atys rezzed, they persist, right? if an object had the right to link to memory module prims it rezzes as needed? is this a silly idea? i like the idea of "prim chips" lol

I used to do the same type of thing in the beta grid. Get a 10 meter tall cylinder and put a script in it that tels it to rez the object inside it 10 meters up. Then you take a copy of that object and put it inside and hocus pocus, next thing you know you have a 2,000 meter tall tower.

But in this case the script will only rez another "prim chip" when it needs to and that "prim chip" has a copy of itself in it's inventory that will do the same thing. Have the script forward the data it needs to, to link X+1 etc. Permissions are already set in the very first "prim chip" and script that you create.

why cant you use lists as a database?

1 space, each element takes up its space + 40 extra bytes, combined with 16k of ram its not alot of space

2 speed, get a cupple hundered elements and prepare to wait minuets

3 redundancy, doesnt take much and whatever was collected in the list is game over, 0, nul, gone

Just depends on what the data is, but if you can afford to loose it then it is much more sim freindly to store data in lists then having to do server calls to get the data from notecards or off site. I set up my teleporter so that I touch one button and it asks what I want to name the location I want to store. I supply a name and then it records the name, sim, location to a list automatically, no fussing with notecards etc. It isn't permanent but it is so fast and simple. It will only display the locations for the sim I am in and I have not lost that data in a year and a half!!!!!!!!! If I do loose it and it resets then it is still easier for me and less hassle to record new locations then it is for any other alternative. I simply hate notecards and have never run into a situation where with a little bit of ingenuity, I was short on memory. Sure just one script doesn't give much memory, but 10 scripts gives a fair amount and 10 scripts are still faster then doing server calls. 100 scripts would be different, but then again I have never felt a desire to build something that would be that hard on a simulator anyways.

oh i totally agree

but on the scale of "why not use a list instead of a webserver" ...

I would have still loved you anyways even if you did disagree Osgeld

aww shucks

i just had an idea (shocker)

use multiple scripts in multiple prims like discussed above

make them phantom and invisible

buy a 16m plot

make a garden

expand land memory as needed + reclaim some neighborhoods

or....

Create multiple scripts within a single prim and communicate data via linked messages.

Try having a system where each script could be with an id. Use that Id to perform read/write/remove operations on the data within that script. If upon adding data to one script would exceed space limits, that script will ask the next script to add that data to its records. If a script with that id doesn't exist, a new one will be created.

ex:

llMessageLinked(LINK_THIS, intScriptId, strRecord, (key) strAction);

Check this out, taken from teh LSL Wiki Hacks:

Permanent Small-Memory Information Storage

Besides using a script's memory as permanent storage (and just never resetting it), a script can store short strings in the object name (using llSetObjectName/llGetObjectName) and description (llSetObjectDesc/llGetObjectDesc) of each prim. If the object is not going to change it's name, use child prims in a link set for that. Floats can also be stored in other object properties such as texture rotation, offset, alpha, scale, etc. Basically anything that has a get/set combination. To store integers, you can simply convert them to floats and back by scaling them down to fit into the usual 0 - 1.0 range.

llSetTexture can also store strings using the typecast (but the object will always have to have full permissions to read back the data), as well as llSetAlpha for floats, llSetColor for vectors. Combined, a lot of information can be stored permanently.

Note: The llSetTexture hack no longer works attempting to specify a texture that is not a valid texture key or not the name of a texture in the objects inventory will return an error "Couldn't find texture (your string)"


Yes its small, but it will stay even through a script reset - plus you can always use more prims if you need to.

True, but it is less flexible and also less secure.