The Data Abstraction Layer will be part of Mantra that will convert the current method of data
storage into an abstract API that Magick will use, regardless of how the data is actually stored.
The current way Magick stores its database requires the XML parser/generator code to be very
intergrated with the Magick classes themselves. This makes it hard for us to be able to change
the method or format in which the data inside or generated by magick is stored. By creating a
data storage abstraction layer, we will be able to change how and where data is stored at will.
This allows for us to be able to do such things as use an SQL database as a back end, or any
other kind of storage we wish to write a driver for.
Mantra must be created.
The Data Abstraction Layer should have two parts. The first to handle how data is accessed and
updated by the application, and the second to handle how that data is stored to whatever medium it
will use as its backend (which should be changable).
The first part (how the data is accessed and updated by the application) will be facilitated by
the creation of a properties system, to replace all the hard-coded veriables used in Magick now.
The properties system will simply be a class with a series of function calls that are used to
retrieve data and update it. These functions will enforce the typing of data, and raise an
exception if the wrong type of data is submitted, or if there was a problem updating the data.
These functions will essentially be wrappers around the data storage layer, and should do little
more than remember 'where' the data that is currently being retrieved or saved is in relation to
the rest of the system, and do checking to ensure the correct type is being used for the data.
There will also be special functions for accessing and updating all properties at once.
The second part (how the data is being stored) is the real heart and soul of the data abstraction
layer. A standard 'Storage API' will have to be implemented, which all data storage drivers must
implement. The Storage API will consist of:
A constructor and destructor to establish the relevant data handles (eg. connect to
the SQL database, or store the database file name, etc), and clean up those handles
respectively.
A method for discovering what data (including type information) is valid from the
underlying storage mechanism. This will probably have to be supplied via. some form
of customized DTD from the application.
A method for retrieving data (and its type) from the underlying storage mechanism, and
passing that on to the properties system. If the storage mechanism is not a 'live'
storage mechanism, it must store this data itself for retrieval.
A method for accepting data (and its type) from the properties system for updating on
the storage medium. If the storage mechanism is not a 'live' storage mechanism, this
will mean updating the internal data storage for saving later on.
A method for retrieving ALL data/type pairs (at once) from the underlying storage
mechanism and passing it to the properties system.
A method for accepting ALL data/type pairs (at once) from the properties system, and
storing a complete record into the storage mechanism.
A method for retrieving a list of all record keys currently in the storage mechanism
for a particular record type.
A method for triggering a save of data. For a 'live' storage mechanism, this does not
need to be implemented, as the default action is a no-op. This will be called when the
application wishes to ensure the database is saved.
A method for triggering a retrieve of data. Once again, for 'live' storage mechanisms,
this does not need to be implemented, as it is a no-op. This will be called when the
application wishes to dump all data currently known, and have it re-loaded from the
physical storage medium (presumably because the application has either just started, or
the data itself has been manually changed).
Magick will have to be changed to have all the veriables currently used to store the data for
each nick, channel, etc. record, to instead use the properties system. The properties system
must be used for EVERY data retrieval, as the back end for storage may be an SQL database that
could be changed at any time, and not necessarily by Magick.
N/A
1. Magick must work as it currently does, loading and saving a compressed encrypted XML file.
2. Any other storage mechanisms developed should be tested to ensure data integrity.
N/A
|
