As far as I can tell, AceDB-3.0 has no direct support for a SavedVariablesPerCharacter table. I assume it's a design choice. But I wonder why? Especially considering that there still is a datatype 'char' that can only be accessed by the current char, it seems natural to me if this dataype could be made to refer directly to a SavedVariablesPerCharacter table.
Otherwise, what's the point of the 'char' dataype'? It will be read in at login and written out at logout. So most of the data will just stay in memory without anyone being able to access it (nor do you want to access it).
I'm aware that AceDB is now fully independent of the addon. This of course means that you can implement your own support for SavedVariablesPerCharacter by creating another AceDB object. However, this object will then have its own profiles, defaults, and callbacks. Is that a good idea?
2.0's per-char stuff was a bit odd really. If I remember right, char profiles (ones picked by the user) were saved into the SVPC, which meant you couldn't clone another char's profile. Something contradictory to the profile design.
I will agree, the 'db.char' path that's hidden from the user should be stored in a SVPC if one is provided. But all user-switchable profiles, even if they're named for the current toon, should be in the main SV. Since it's just that one path, personally I'd just use a manual DB for the PC stuff, instead of AceDB... but that's just me. AceDB is designed around user settings and switchable profiles, where as SVPC are usually used to store data not directly accessible by the user, for example bank inventory dumps, quest history... none of which need the fancy default stuff AceDB provides.
MyAddon:RegisterDB("MyAddonDB", "MyAddonCDB", "char")
Which SV is that profile saved into? If it's MyAddonCDB that's what I'm saying is wrong. It's been a long time since I've used AceDB-2.0 so I don't remember, but I vaguely recall it behaving in a manner I didn't expect.
Like I said above, profiles should go in the global SV to allow for access on any toon, only db.char should go into the SVPC.
Wether or not Ace2 implemented it properly, I think it's relevant to discuss if Ace3 should implement this. :)
My take on it is that it would be a very welcome convenience if the 'char' datatype could be made to refer to the SVPC (or just any table specified for that matter). On the other hand, if it is problematic for some reason to implement, it could be left out since authors do have other options.
So I hope those responsible for AceDB-3.0 will investigate the issue if they haven't already. Jira ticket perhaps?
I agree with Ammo. Whats the advantage of storing it in the SVPC and not in the "Char" profile in your main SV?
I guess a weeeee bit of memory *shrug*.
The SVPC is a easy way for addons to create character based configs, without a complex framework to do that for them, but with AceDB datatypes or profiles, that advantage is nil'ed,
Ok, I know this is an old topic, but I can think of one advantage that SVPC has over how AceDB currently does it.
When a character is renamed, the client automatically renames the associated directory under WTF, so anything using SavedVariablesPerCharacter "just works".
AceDB's char tree, as well as the per-char profiles (which are the default for some mind-boggling reason), index by character name. So when a character is renamed, you lose all the associated settings.