Updating Table Values (I think that is what I am asking)

Morant · 08-08-09, 09:42 PM

I have a table for defaults. A copy of which is saved in the WTF folder and loaded as MainOptions.

Code:

local MainDefaults {
    ["MainOnOff"] = 1,
    ["OptionWhatever"] = 1,
...

    ["Version"] = "0.21",
}

I have implemented a statement that checks:

Code:

if (type(MainOptions["Version"]) == "string") or (MainOptions["Version"] < MainDefaults["Version"]) then
UpdateVersion()
end

The first few versions of this I have released have the version set to 1.0b - not a number so I want to account for those by checking to the type"string". The reason the new value is a decimal is to signify beta in a number (below 1) without using string types.

Now for the trouble:

I have tried in vain but can not figure out why..

Code:

function VersionUpdate()	
	if not MainOptions then
		MainOptions = MainDefaults
	end
	local MainOptionsTemp = MainDefaults
	for k,v in pairs (MainOptions) do
		if (MainOptions[k] ~= MainOptionsTemp[k]) then
			MainOptionsTemp[k] = MainOptions[k]
		end
	end
MainOptions = MainOptionsTemp	
MainOptions["Version"] = MainDefaults["Version"] 
MainOptionsTemp = nil
end

Will not update the "Version" value correctly. Everything else is fine I think, not tested fully yet though. Can't get past this. I think I am trying to update the value of "Version" in the table:MainOptions incorrectly and I can not locate any reading material that helps.

I found tinsert() but that doesn't seem to be right.

Comments? Assistance?

/cheers

Akryn · 08-09-09, 12:15 PM

Two things immediately jump out:

1. "pairs (MainOptions)" shouldn't have a space -- I'm actually not sure if that matters in Lua, I've never tried it.
2. Table variables are pointers. If you do this:

Code:

local a = {1,2,3}
local b = a
b[2] = "elephant"
print(a[2])

you will get "elephant" -- I think that's your main problem. You might also be calling your update function before the variables load?

Foxlit · 08-09-09, 12:41 PM

Code:

local MainOptionsTemp = MainDefaults -- < This is a reference, not a copy
for k,v in pairs (MainOptions) do
	if (MainOptions[k] ~= MainOptionsTemp[k]) then
		MainOptionsTemp[k] = MainOptions[k] -- < This runs for k="Version", setting MainDefaults.Version = MainOptions.Version
	end
end
-- ... 
MainOptions["Version"] = MainDefaults["Version"] -- < Has no effect, as MainDefaults.Version == MainOptions.Version already.

Morant · 08-10-09, 02:06 PM

Thank you both. I have thought on this and here is what I come up with... Please correct me if I am out there somewhere...

you will get "elephant" -- I think that's your main problem.

Let me understand

Code:

local MainOptionsTemp = MainDefaults -- < This is a reference, not a copy

better.

I reason then if you want a copy of the data contained in [k] then you would have to:
for k,v ...

local TempVariable = MainOptions[K]

... update current defaults and then check back to the TempVariable for what the previous setting was and if it is not the same as the defaults now loaded, update it..

MainOptions[k] = TempVariable

Yes? Even if not exactly right for this particular code block, my logic of it is my concern.

NOTE: Something discovered is that some of my variable are able to be set to = 0. In the SavedVariables .lua this equates to no entry for that particular tables [k]... thus when comparing the user settings to defaults the ones set to zero are not processed as they are "nil". Have to rethink this with that in mind. But the above really helps in understanding what I am asking it to do.

Akryn · 08-10-09, 04:55 PM

You don't have to write the function yourself any more, fortunately:

b = CopyTable(a)

Crowfeather · 11-01-10, 06:09 AM

Found this via search as I had a very similar Problem. CopyTable solved that problem but unfortunatly it also caused memory consumption of my addon to spike. It looks like instead of overwriting an existing table (if it exist) it creates a new one everytime it is used. So if I did something like self.button1.resources = CopyTable(self.resources) where resources is a rather large object table once every half second or so it allocated new memory for the table everytime it's called. I guess it'd be garbage collected eventually but still it is kind of wasteful if my 130 KB AddOn uses a several megabytes of memory after a few minutes.

I resorted to copy the table by hand as Morant suggested in his last post and it works but it's kind of annoying and if there're values in the target table that are nil in the source table I have to delete them explicitly. I'm propably going to code my own version of CopyTable that does all this but before I do wanted to ask if I missed something important or if someone else has already done that work.

Xubera · 11-01-10, 03:10 PM

well nevermind this post is over a year old but

Code:

local table1 = {
    settings = false,
    option1 = true,
    option2 = 0.5,
    option3 = "LEFT",
    option4 = nil
}
local table2 = {}
--to copy the table, we use pairs
for k,v in pairs(table1) do
    table2[k] = v
end

this would make table 2 have every key and value as table1 except for option4, because not even table1 has option4 (because its nil).

if you wanted to do something like to check if a user has saved variables in the beginning you would do

Code:

local defaultOptions = {
    option1 = false
    option2 = true
    option3 = 0.5
    option4 = "LEFT"
}

for k,v in pairs(defaultOptions) do
    if myAddonDB[k] ~= nil then
       myAddonDB[k] = v
    end
end

the reason it is myAddonDB[k] ~= nil instead of not myAddonDB[k] is because both false and nil would return true for not myAddonDB[k] therefore overriding any option set to false. with nil, it will set any option that doesnt exist. Using this method, anytime you set your settings to the false position, you need to save it as false, and not nil for this reason