Ferreteria/v0.5/portbank: Difference between revisions
< Ferreteria | v0.5
Jump to navigation
Jump to search
No edit summary |
(saving work; not done) |
||
| Line 2: | Line 2: | ||
v0.5 includes a [[wooz:2021/11/08/data objects refactoring|significant refactoring of how database-related objects are managed]]. The goal was to simplify access to global singleton objects in general, and databases and tabloids in particular, while retaining flexibility (e.g. for different applications to determine the database in which each table is stored). | v0.5 includes a [[wooz:2021/11/08/data objects refactoring|significant refactoring of how database-related objects are managed]]. The goal was to simplify access to global singleton objects in general, and databases and tabloids in particular, while retaining flexibility (e.g. for different applications to determine the database in which each table is stored). | ||
==Databases== | ==Databases== | ||
Creating a database requires a database spec (<code>ferret\data\cDatabaseSpec</code> descendant). | Creating a database requires a database spec (<code>ferret\data\cDatabaseSpec</code> descendant). ''(yes, I know this bit is hopelessly incomplete)'' | ||
==PortBanks== | |||
===Structure=== | |||
* A '''PortBank''' is a Table-configured object which contains a set of '''PortRow'''s (which, by default, it creates). Each PortRow has a Type string. In theory there can be any number of these for different types of I/O, but in practice (caPortIOBank) there are 3 types: | |||
** '''Native''', which is used only for internal calculations (no I/O) | |||
** '''Storage''', which converts to and from SQL (or, in theory, any other database-storage format) | |||
** '''Display''', which converts to and from HTML (or, in theory, any other display markup) | |||
* A '''PortRow''' contains a set of '''PortUnit'''s, one for each field in the Table. | |||
===Access=== | |||
* Each '''PortRow''' keeps a pointer to its containing '''PortBank''' object. All access to other PortRow types in the PortBank is via the PortBank. | |||
* A specialized '''PortBank''' class, called a '''SpaceIOBank''', expects a Space object in its constructor, and retains it. This provides access to the parent Table and the current Rowset and Record, where applicable. (Pretty much everything descends from SpaceIOBank rather than PortBank.) | |||
===Data=== | |||
* There is one '''PortBank''' per '''Table'''. | |||
** We don't create additional PortBanks to retain values for rows other than the current one. This is mainly to avoid having to repeatedly execute all of the setup that goes into creating a PortBank and all its contents (Rows, Units). | |||
* '''PortRow''' has an <code>OnCursorSet()</code> event which should be called whenever the current row changes. ''(2021-12-07 It's not clear whether this is actually in use.)'' | |||
* A PortRow creates its own objects, but by default it needs to know the name and class to use for each one. | |||
** A descendant class, '''PortRowInternalDirect''', has a default Unit class to use if one is not specified. | |||
Revision as of 16:07, 7 December 2021
Data Object Management
v0.5 includes a significant refactoring of how database-related objects are managed. The goal was to simplify access to global singleton objects in general, and databases and tabloids in particular, while retaining flexibility (e.g. for different applications to determine the database in which each table is stored).
Databases
Creating a database requires a database spec (ferret\data\cDatabaseSpec descendant). (yes, I know this bit is hopelessly incomplete)
PortBanks
Structure
- A PortBank is a Table-configured object which contains a set of PortRows (which, by default, it creates). Each PortRow has a Type string. In theory there can be any number of these for different types of I/O, but in practice (caPortIOBank) there are 3 types:
- Native, which is used only for internal calculations (no I/O)
- Storage, which converts to and from SQL (or, in theory, any other database-storage format)
- Display, which converts to and from HTML (or, in theory, any other display markup)
- A PortRow contains a set of PortUnits, one for each field in the Table.
Access
- Each PortRow keeps a pointer to its containing PortBank object. All access to other PortRow types in the PortBank is via the PortBank.
- A specialized PortBank class, called a SpaceIOBank, expects a Space object in its constructor, and retains it. This provides access to the parent Table and the current Rowset and Record, where applicable. (Pretty much everything descends from SpaceIOBank rather than PortBank.)
Data
- There is one PortBank per Table.
- We don't create additional PortBanks to retain values for rows other than the current one. This is mainly to avoid having to repeatedly execute all of the setup that goes into creating a PortBank and all its contents (Rows, Units).
- PortRow has an
OnCursorSet()event which should be called whenever the current row changes. (2021-12-07 It's not clear whether this is actually in use.) - A PortRow creates its own objects, but by default it needs to know the name and class to use for each one.
- A descendant class, PortRowInternalDirect, has a default Unit class to use if one is not specified.