DataStore is the main component of a series of addons that serve as data repositories in game. Their respective purpose is to offer scanning and storing services to other addons.
The advantages of this approach are:
- data is scanned only once for all client addons (performance gain).
- data is stored only once for all client addons (memory gain).
- addon authors can spend more time coding higher level features.
- each module is an independant addon, and therefore has its own SavedVariables file, meaning that you could clean _Crafts without disturbing _Containers.
Scope : a note to contributing authors
The core of the database is based on my work in Altoholic, and is thus designed with multiple-account support in mind. If client addons want to store data from foreign accounts, the database will be ready for it. Nothing is final at this point though, feel free to contribute, as the concept can and will be perfected.
The scope of each addons is to provide common methods for client addons. For instance, DataStore_Crafts embeds LibPeriodicTable-3.1-Tradeskill allowing it to give more than just scanning & storing data. However, the goal is not to put _everything_ into these addons, they must be seen as an abstraction layer and a service provider, nothing more.
These libraries cannot and should not be embedded, as they all manage their respective SavedVariables.
Existing modules
- DataStore_Achievements : Achievements
- DataStore_Auctions : Auctions & Bids
- DataStore_Characters : Base information about your characters
- DataStore_Containers : Bags, Bank and Guild Banks
- DataStore_Crafts : Tradeskills & Recipes
- DataStore_Currencies : Currencies
- DataStore_Inventory : Equipment
- DataStore_Mails : Mails
- DataStore_Pets : Companions & Mounts
- DataStore_Quests : Quest log
- DataStore_Reputations : Reputations
- DataStore_Skills : Character skills (weapons/etc..)
- DataStore_Spells : Spells
- DataStore_Stats : Character Statistics
- DataStore_Talents : Talent trees & Glyphs
Each module will exist as a separate addon, so that authors can package only the ones they want with their own project.
More modules will come later.
Information Pages
- Project overview : A slightly more detailed overview of the scope
- API : Samples of commonly used methods (work-in-progress)
- 5 comments
- 5 comments
Facts
- Date created
- 30 Jul 2009
- Category
- Last update
- 16 Nov 2009
- Development stage
- Release
- License
- All Rights Reserved
- Curse link
- DataStore
- Reverse relationships
- 1
- Recent files
- A: r12 for 3.2.0 on 16 Nov 2009
- A: r11 for 3.2.0 on 28 Sep 2009
- R: DataStore 3.2.002b for 3.2.0 on 19 Sep 2009
- A: r10 for 3.2.0 on 19 Sep 2009
- R: DataStore 3.2.002 for 3.2.0 on 14 Sep 2009
- #5
mikk Thu, 08 Oct 2009 12:08:54Just a followup: Yes, if people are installing something disembedded, the code would still end up in the addons themselves, but that's nondestructive since standard lib upgrade mechanisms would use the latest code from some newer, embedded copy.
- #4
Thaoky Wed, 07 Oct 2009 12:11:03Very good idea. It may be a while before I get there due to the time I have to grant to coding these days, but definitely an objective for somewhere between 3.3 and 4.0.
- #3
mikk Fri, 02 Oct 2009 13:29:30It strikes me that this is avoidable if the DataStore addons only contain savedvars and no code, and the code is instead embedded as regular libraries.
- #2
Thaoky Mon, 28 Sep 2009 14:53:52Hey mikk,
Yup, I know about this, and that's something I want to avoid too. I discussed this with cf admins before launching the projects and that was not possible at that time. I will try to put the subject on the table again to see if there's a chance to make it happen.
Thanks for you input :)
- #1
mikk Sun, 27 Sep 2009 21:01:14Something you might want to take into account:
If addons package DataStore in their zips, hilarity will ensue when update time rolls around, and people end up installing old DataStores on top of newer versions, just because some addons zips were last generated too long ago.
This should be theoretically solvable if all such addons live on cf/wowace, and the packager know to update their zips when DataStore changes. It USED to do this for lib changes too back in the day, but that got a bit too crazy.
Maybe the cf crew could be convinced to add a special type of "external" that is offset from the root zip dir, and causes zip updates when the external changes... hm..