Databases are the core type in Sterling you will interact with in order to manage the instances of your classes and types. Databases are registered with 3. The Sterling Engine and there is only one instance per type of database. Databases handle the saving and loading of data, deleting and purging, as well as indexes and keys. They are very important for the operation of Sterling.
Keep in mind that databases in Sterling are strongly typed because the structure of the database is important. Sterling contains special keys and references to keep track of objects, and changing the database "on the fly" can result in unexpected results. If you need to change the database by modifying a type or adding an index, for example, you should create a new database type and migrate the old code. Some strategies for doing this are explained in the 7. Sterling Recipes.
Registering the Database
Sterling is a very powerful serialization engine. It will walk through complex object graphs and automatically serialize lists, dictionaries, enums, even other classes. However, at the root Sterling must have an object with a unique key. This allows Sterling to save a unique instance of that object and manage that instance individually. The classes or types that you register with Sterling can be thought of as table definitions, which is why the method call is referred to as _RegisterTables. When you register a table, all of the tables publicly accessible properties that can be read and set will be automatically serialized. To register a table, you must specify the type for the class and the type for the key, and a lambda expression that explains to Sterling how to get the key value from the class (for example, a class with an integer key may have a dozen integer properties, so Sterling must know what the appropriate properties are).
In the override to register tables, you will use the protected CreateTableDefinition helper method to define the table. You can supply a comma separated list of table definitions to provide multiple tables. The following is an example list of tables from the test project contained within Sterling:
Databases inherit from BaseDatabaseInstance. There are two overrides: the name (should be unique per application) and a method to define tables. Tables are defined in a command-delimited list. You are required to specify the type for the table, the type of the unique key for the table, and a lambda expression that shows Sterling how to obtain the key. Indexes are optional and can be defined using the WithIndex extension method. The following example shows a database that defines multiple tables with different keys and indexes from the Sterling unit tests.
Database initialization really does three main things. First, it loads the associated table definitions into memory and generates all of the internal mechanisms necessary to parse, save, and load the defined data types. Second, the keys are loaded into memory. Third, the indexes are loaded into memory. At this point it is possible to perform LINQ to Object queries over the tables and indexes to query values.