For example, if we want to print out the items in the player’s backpack (bag 0) in order of descending quantity, we could perform a query against the database which would look like the following: A query is the only way to read data from the database as it allows us to do much more complicated things than just iterating through a regular lua table, and in some cases can be significantly faster. Having this well-defined data structure also allows us to access and filter the data in a standardized way, which is done by making queries against the database.
How the database library actually stores the data within the database is an internal implementation detail, and is cleanly abstracted from the higher-level application logic. :SetField(“autoBaseItemString”, autoBaseItemString)Īs you can see, we simply create a new row, set all the fields which are defined by the schema, and then call :Save() which will cause the new row to be inserted into the database.
#TRADESKILLMASTER GUIDE PHAT LEWTZ CODE#
Here’s an example of what the code to insert a new row in our player bag tracking database looks like: One place in which the database library enforces this is when a new row is inserted into the database. This means that the database will contain a set of rows which are guaranteed to all have the exact same fields, and therefore can be used by the higher-level application logic in a standardized way. Now that we’ve defined the schema (aka structure) of the database, any time we want to insert into the database, the library will enforce that the data we are inserting (aka the row) confirms to this schema. Our database library also supports special attributes such as “unique” and “index” which are more advanced constraints on the data which can be stored within the database and allow for the data to be stored and retrieved more efficiently. The fields closely match the list I gave above. Here is how the database gets defined for tracking the player’s bags:Īs you can see, we define all the fields (aka columns) of the database and their type. With this new database library, we can store all this information in a strictly defined and centralized manner, and the varying consumers can make queries against it to satisfy their own individual use-cases. This lead to a lot of duplicated effort as we were scanning the player’s bags multiple times to track the various pieces of data which we care about. In TSM3, the code which tracked this information was scattered across multiple places in the codebase, and the data was stored in a variety of different lua tables, each with their own structure. For each slot of a player’s bags which contains an item, there is a well-defined set of attributes which we care about: This dataset is used for many things including calculating inventory quantities for display in tooltips and use in varying features such as restocking via Crafting and determining what items can be posted on the auction house with an Auctioning Post Scan. One of the things which TSM tracks is the exact contents of the player’s bags. Let’s dive into how our database library accomplishes these things.
#TRADESKILLMASTER GUIDE PHAT LEWTZ UPDATE#
Another goal was to be able to connect UI elements to underlying data in a standard way which would allow the UI to update itself automatically when there are changes to the underlying data. Our main motivation for creating this database library was to make it easier to represent large datasets in a very structured way which could easily be consumed by the higher-level application logic. This new database library is made possible by the class library which I discussed in a previous blog post.
This is an internal code library which makes it easier for us to implement new features in TSM4. This is another very technical blog post which provides a look into the new database library which has been added to the TSM codebase with TSM4.