don't save information based on name
chancedj opened this issue · 10 comments
for clients that are on different language servers, it causes a problem to save by name. it should save by a unique key (currencyid, bossid, etc) instead of using the name so that we don't duplicate information for the user.
Example used was EU vs RU - mixing the RU and EU currency names.
example link
If I recall correctly, SavedInstances uses constants to look up the IDs and then stores stuff using them. I'd probably do the same, although I haven't given the problem much thought.
Example:
Currencies.ANCIENT_MANA = 1115 (Currencies being some lookup table)
You can then still use the key, ANCIENT_MANA (instead of writing "Ancient Mana", the name), which combines both data sets in the same table no matter if the user is logging in with a ruRU or enGB/enUS client.
To display it, L["Ancient Mana"] and it'll show in the currently active client's locale.
Thanks. That's the plan... To switch to an I'd... Either the currency I'd or incremental table I'd.
I built out the constant table last night and marked everything I could with the proper expansion and if it is available anymore. So now I can use that for display and to sort by expansion. I'll either fix it this release or next release.... Depending on how much work it will cause. I think with how I will need to implement the table they will likely be done this release since I'm already breaking the format once for everyone :)
i actually have my own table built (created from the currency api). it may be similar, but i decided to go that route since if i leave the code as is, i can use it to build any missing currencies as well.
If you're talking about the saved variables, you can try building an incremental migration routine for them - set a database version and then for each one there can be (optional) migration steps that will be applied on startup to transform the DB structure from the previous version.
That way, the work will only have to be done once and there's no risk of breaking the saved variables afterwards if you consider no version as version = 0 and apply all changes incrementally.
yes....but we're talking about 2 different tables :). the table i'm referring to is the "lookup" table.
see this commit: e4d9d9e
Yeah, but you said you'd have to "break" the format for the users - which you don't really need to do if you make sure to always update their saved variables DB when you are changing its layout :)
Well, don't mind me, then. I'm just watching and leaving some more or less random comments from time to time :)
your feedback is very much appreciated....don't mean to give off any ideas to the contrary :)
