copy SV table with additions

[myrroddin]

It occurs to me that users of SmartRes2 have added their own phrases to the table SmartRes2.db.profile.randChatTbl, and with my rewrite, I am moving that table into a module called Chat.

I found a copy table function that will work well enough, assuming that Chat.db.profile.randChatTbl was empty, but it is not empty -- it has its own default values, 25 of which duplicate the original SR2 built-in defaults.

I could copy it straight up with Chat.db.profile.randChatTbl starting as an empty table, but that won't work if the user resets the profile, as there won't be default values to restore. Chat.blah needs default values.

Therein lies the trouble. Not only do I NOT want to create duplicate entries, I also do not care if the user deleted some or all of SR2's defaults (there is an option to do so). I am only interested in copying the values that are new or different. So now I am confused, mainly because the examples linked are not fully documented on what and how they are doing things, and most of the variables are not very descriptive.

tl;dr: copy only user-defined phrases from SmartRes2.db.profile.randChatTbl to Chat.db.profile.randChatTbl and then wipe SmartRes2.db.profile.randChatTbl because it will become defunct.

How do I go about doing this?

[myrroddin]

Wow, rereading that post, and I don't think it made sense, so an example. Keep in mind that I would have absolutely no idea what phrases the user added.

-- exists in both SR2.db and Chat.db, therefore ignore this phrase during copy
"%p is bringing %t back to life!"
 
-- user-defined, so copy this to Chat.db
"By the Light, I am resurrecting %t"
 
-- in SmartRes2.db, but user removed, but that doesn't matter because it exists as a default phrase in Chat.db anyway
"Once again, %p pulls %t and their bacon out of the fire."

[myrroddin]

would this work?

local function CopyAndDeleteTable(source)
    if #source = 0 then return end
    local dest = Chat.db.profile.randChatTbl
    for sk, sv in pairs(source) do
        for ck cv in pairs(dest) do
            if not string.match(dest, sv) then
                table.insert(dest, sv)
            end
        end
    end
    wipe(source)
end
 
function Chat:OnInitialize()
    CopyAndDeleteTable(SmartRes2.db.profile.randChatTbl)
end

[myrroddin]

This might work better, because I think it is just a simple table, and not key, value. Maybe?

local function CopyAndDeleteTable(source)
    local dest = Chat.db.profile.randChatTbl
    for i = 1, #source do
        for c = 1, #dest do
            if not string.match(dest[c], i) then
                table.insert(dest, i)
            end
        end
    end
    wipe(source)
end

[Gethe]

As they are, both would likely not work as you expect. In your first version, 'dest' is a table and would thus raise in an error. It should probably be 'cv'. In the second version, 'i' is a number which is probably not your intended comparison. It should probably be 'source[i]'.

Regarding the use of pairs vs #table. It really depends on whether or not the table order matters. There may be some slight performance benefit from the second method, but it probably won't be noticeable at this scale. For convenience, there is also ipairs that works similarly to pairs, but respects table index.

Putting those aside, the function would still not work as you describe because as written it would add the string from 'source' multiple times for each mismatch. This would result in a lot of duplicate entries. The way to do it is to traverse the entire destination table before adding the new string. This assures that 1) If the string already exists, but is at the end of the table, it isn't added again prior to that check, and 2) It is only added once.

local function CopyAndDeleteTable(source)
    local dest = Chat.db.profile.randChatTbl
    for si, sv in ipairs(source) do  -- Using ipairs here mostly as an example of usage.
        local hasMatch
        for ci, cv in ipairs(dest) do
            if string.match(cv, sv) then
                hasMatch = true
                break -- We found a dupe, no need to go farther
            end
        end
        if not hasMatch then
            table.insert(dest, sv)
        end
    end
    wipe(source)
end

Finally, are you planning to do anything else with the old table? If not, using wipe() will only remove keys and indexes on the table, the table itself will still exist. To delete it, you would have to reassign the table as nil. In this case you would have to move the delete part out of CopyAndDeleteTable because assigning nil to 'source' would only delete that reference, not the actual table.


All together:

local function CopyTable(source)
    local dest = Chat.db.profile.randChatTbl
    for si, sv in ipairs(source) do  -- Using ipairs here mostly as an example of usage.
        local hasMatch
        for ci, cv in ipairs(dest) do
            if string.match(cv, sv) then
                hasMatch = true
                break -- We found a dupe, no need to go farther
            end
        end
        if not hasMatch then
            table.insert(dest, sv)
        end
    end
end
 
function Chat:OnInitialize()
    CopyTable(SmartRes2.db.profile.randChatTbl)
    SmartRes2.db.profile.randChatTbl = nil  -- delete the now unused table
end

Hope this helps!

[myrroddin]

It helps immensely, as you can see from my prior attempts! Thank you very much.

1) no, I was not planning on using the old table, and do want it removed entirely from the DB, so your last bit should work.
2) maybe just because I'm tired, but the break's position isn't going to prevent the parser from continuing to find non-matches to copy, right?

[Gethe]

Originally Posted by myrroddin 2) maybe just because I'm tired, but the break's position isn't going to prevent the parser from continuing to find non-matches to copy, right?

No, break will only exit the innermost loop.

[Seerah]

return would exit out completely.

[myrroddin]

Once again, thank you! I have to stop looking at code, and/or writing code when I'm tired

Hopefully the users, when it all gets released, appreciate these little things. I certainly didn't have to try to salvage their old settings.