I'm having a bit of a problem that I really hope doesn't need to be solved by using temporary tables. Basically, I want an indexed table saved via AceDB to be accessible in the order of its indices. In "normal" LUA this would be pretty straightforward, its just what pairs() does. But it isn't quite happening with AceDB, and I'm wondering if that is because of the use of metatables. I confess to a bit of ignorance on just how metatables work.
Here are two examples of the problem:
1) After adding items to the indexed table via foo.db.char, I then table.sort(foo.db.realm), and the indices are correct for the lexical ordering of the values: 1 points to the alphabetical first item, 2 points to the second, etc. However, iterating through the table with pairs() prints the items in a non-obvious order. First it might print key 5 and its value, then key 2 and its value, then key 1 and its value, then key 4 and then key 3.
2) After appending an item to the end of an indexed table with table.insert(foo.db.char), it exhibits this same problem as the first: pairs does not go through the table "in order" -- the order in which items were placed in the table -- but rather some unclear order. This breaks the logic of my code which is using the table as a queue.
Any way around this *without* building up temporary tables? Is this happening because of metatables or some other thing? Is it possibly something that can be fixed in AceDB itself?
Ever go to bed thinking about a programming problem like this then wake up and think, "Gee, I wonder if it is as easy as..."
I woke up thinking about ipairs() instead of pairs().
Just tested it, at least for case #1. Works now.
Boy do I feel stupid.
The weird part for me is that in my past experience, as well as in the documentation at lua.org and lua-users.org, pairs() has returned the indexed part of a table in order; no part of the documentation suggests that this is not always the case with pairs(). Guess this isn't guaranteed, and maybe it has nothing to do with metatables. I could understand that. Anyway, fixed now. Tempting to erase this beacon of my stupidity, but maybe my stumbling will help someone else who encounters the same sort of problem.
HOWEVER, you are right in that in the manual, the next() function, which pairs() points to for caveats about modifying the table during its traversal. I didn't chase down that reference the first time because I wasn't modifying the table during traversal so the note, to the typical reader, wouldn't seem to apply. So still, the warning about ordering issues does not appear with pairs() itself.
So allow me to restate: "The documentation regarding pairs() and ipairs(), including the LUA wiki where many programmers new to LUA are most likely to learn about specific aspects of the language work in practice, is unfortunately very weak in noting that pairs() does not iterate through the keys of an indexed table in order."
Do you disagree with this remark? Ah well, not sure if it matters to me whether you agree or not. At least I'll take some action to edit the LUA-users wiki to attempt to make this more clear for others.
Here are two examples of the problem:
1) After adding items to the indexed table via foo.db.char, I then table.sort(foo.db.realm), and the indices are correct for the lexical ordering of the values: 1 points to the alphabetical first item, 2 points to the second, etc. However, iterating through the table with pairs() prints the items in a non-obvious order. First it might print key 5 and its value, then key 2 and its value, then key 1 and its value, then key 4 and then key 3.
2) After appending an item to the end of an indexed table with table.insert(foo.db.char), it exhibits this same problem as the first: pairs does not go through the table "in order" -- the order in which items were placed in the table -- but rather some unclear order. This breaks the logic of my code which is using the table as a queue.
Any way around this *without* building up temporary tables? Is this happening because of metatables or some other thing? Is it possibly something that can be fixed in AceDB itself?
Thank you in advance for any insight.
I woke up thinking about ipairs() instead of pairs().
Just tested it, at least for case #1. Works now.
Boy do I feel stupid.
The weird part for me is that in my past experience, as well as in the documentation at lua.org and lua-users.org, pairs() has returned the indexed part of a table in order; no part of the documentation suggests that this is not always the case with pairs(). Guess this isn't guaranteed, and maybe it has nothing to do with metatables. I could understand that. Anyway, fixed now. Tempting to erase this beacon of my stupidity, but maybe my stumbling will help someone else who encounters the same sort of problem.
It does.
No part of the documentation which mentions pairs() or ipairs() at:
http://lua-users.org/wiki/TablesTutorial
http://lua-users.org/wiki/TableLibraryTutorial
http://lua-users.org/wiki/ForTutorial
http://www.lua.org/manual/5.1/manual.html
says anything about ordering issues.
HOWEVER, you are right in that in the manual, the next() function, which pairs() points to for caveats about modifying the table during its traversal. I didn't chase down that reference the first time because I wasn't modifying the table during traversal so the note, to the typical reader, wouldn't seem to apply. So still, the warning about ordering issues does not appear with pairs() itself.
So allow me to restate: "The documentation regarding pairs() and ipairs(), including the LUA wiki where many programmers new to LUA are most likely to learn about specific aspects of the language work in practice, is unfortunately very weak in noting that pairs() does not iterate through the keys of an indexed table in order."
Do you disagree with this remark? Ah well, not sure if it matters to me whether you agree or not. At least I'll take some action to edit the LUA-users wiki to attempt to make this more clear for others.
Thank you for your help. Must be rewarding.
http://www.lua.org/pil/19.3.html
Thanks! I've also just now completed updating the Tables, TableLibrary and For pages at the lua-users.org library to make it clear there too.
I see you've already elaborated some, so I guess I don't have to spend my time at work digging up documentation links anyway :)