You could have Load/Save methods in the derived types that override those in the base class.
The base class list handling is properly shared but when it comes to loading or saving an instance the override methods are called.
It sounds to me like you should rethink the overall design. I don't see any reason for the individual types to extend Database. Perhaps they should be types derived from a base Row type ?
Here is a rough outline of how a database structure could be implemented:
- There is a type T_Database that holds everything together and provides initialisation, finalisation and perhaps if required CreateTable, DropTable, statistics etc. It also provides things like the file or directory path and a collection (say a list or array) of T_Table objects
- T_Table contains a collection of T_Column types that define the fields and a collection of T_Row types that store the data in this format. T_Column is only really required if you want to allow for the database to understand the row structure. This is important if you want to implement things like Select with a Where clause or indexes on certain columns.
- T_Row is the base for the types that will actually be stored and manipulated. From it are derived say T_Enemy and T_Planet which are the types you want to handle. The derived types know which T_Table they are related to and they implement override methods to construct themself from (Load) or store themself to (Save) a string, stream, bank or whatever is your physical storage mechanism.
- T_Row contains a lot of the code in methods like Insert, Update, Delete, Select. These are generic and rely on the derived Load/Save methods to operate on the specific type instances. Often the function/method parameters and return values will be variables or arrays of type T_Row. In your calling program of course they will be of the derived types T_Enemy etc which are compatible since they are derived from T_Row.
This can get as sophisticated as you want. Even if you are starting with the simple stuff, think about what the objects actually are and what actions they perform.
- A database is a collection of tables. Databases can be created and dropped.
- A table is a collection of columns that define the fields and a collection of rows that contain the data in that format. Tables can be created and dropped.
- A row contains the fields that make up a single entity. Rows can be inserted, updated, deleted or selected
Perhaps somebody has already made either a BlitzMax interface to a proper DBMS or a DBMS like structure that would meet your requirements ?
The base class list handling is properly shared but when it comes to loading or saving an instance the override methods are called.
It sounds to me like you should rethink the overall design. I don't see any reason for the individual types to extend Database. Perhaps they should be types derived from a base Row type ?
Here is a rough outline of how a database structure could be implemented:
- There is a type T_Database that holds everything together and provides initialisation, finalisation and perhaps if required CreateTable, DropTable, statistics etc. It also provides things like the file or directory path and a collection (say a list or array) of T_Table objects
- T_Table contains a collection of T_Column types that define the fields and a collection of T_Row types that store the data in this format. T_Column is only really required if you want to allow for the database to understand the row structure. This is important if you want to implement things like Select with a Where clause or indexes on certain columns.
- T_Row is the base for the types that will actually be stored and manipulated. From it are derived say T_Enemy and T_Planet which are the types you want to handle. The derived types know which T_Table they are related to and they implement override methods to construct themself from (Load) or store themself to (Save) a string, stream, bank or whatever is your physical storage mechanism.
- T_Row contains a lot of the code in methods like Insert, Update, Delete, Select. These are generic and rely on the derived Load/Save methods to operate on the specific type instances. Often the function/method parameters and return values will be variables or arrays of type T_Row. In your calling program of course they will be of the derived types T_Enemy etc which are compatible since they are derived from T_Row.
This can get as sophisticated as you want. Even if you are starting with the simple stuff, think about what the objects actually are and what actions they perform.
- A database is a collection of tables. Databases can be created and dropped.
- A table is a collection of columns that define the fields and a collection of rows that contain the data in that format. Tables can be created and dropped.
- A row contains the fields that make up a single entity. Rows can be inserted, updated, deleted or selected
Perhaps somebody has already made either a BlitzMax interface to a proper DBMS or a DBMS like structure that would meet your requirements ?