[Corelinux-public] Begining Draft on Persist and Schema

[Frank V. C. <fr...@co...>]

Schemas and Persistence
=======================

Premise
-------
The persistence abstraction is built on the premise that the actual 
storage service code, that which implements concrete persist services
beneath
the abstraction, should be intelligent enough to take guidance from
domain
descriptions (concepts). Said concepts define the types to be stored, in
addition to
other information, and it is the job of the storage service to manage
the data layout 
and service execution as defined by it's implementation.

It is, after all, the 21st century.

This benefits the application developer from having to worry about
the details of a particular storage service, as well as having
the flexibility to change persist implementations at will, or by user
choice. 

Overview
--------
There are actually two (2) aspects to the CoreLinux++ Abstract Persist
framework: Schemas and Services. This release focuses on the newly
provided Schema constructs. * Please refer to the current implementation 
restrictions at the end of this document.

A Schema is an organization of concepts to model an idea. In this case,
what is being modeled are the types that the application will want
to have made persistent. When a schema has been modeled, it is then
usable
as a roadmap, in effect, to guide the storage implementation. For
example,
the types may represent tables in a relational database storage service,
or a file type for a flat file service. It is ultimatley up to the
service
to decide how to "plan the trip".

There are two (2) workflows around Schemas and their concepts: Model and
Run. Lets talk turkey first:

Schema Modeling
---------------
Schema modeling is supported through built-in services and functions of
the library. 
All modeling changes are persisted to gdbm databases, and the domain
modeler 
need only focus on making their schema correct. While there is a
tremendous 
opportunity for adventerous open source developers to build tools 
around this (GUI, etc.), the library contains the fundemental
capabilities to 
Create, Request, Update, and Delete Schemas or their artifacts
(concepts).

The example test driver (clfw/src/testdrivers/exf2) shows some of the
fundemental
capabilities.

Current Implementation Restrictions
=================================== 

Name/Value Declarations
-----------------------
While ultimately Schemas and Concepts attributes won't be limited as to
the
depth or types supported, the current implementation assumes most
attributes
are of the form: Name:Value, where:

Name is the Key data member of the Attribute and should be of type
FrameworkString
Value is the Value data member of the Attribute and should be of type
FrameworkString

Primary Schema Declarations
---------------------------
For schemas, the following are the recognized attribute keys:

    Attribute Key  : "Name"
    Expected Value : Unique name for this schema
    Example: "Franks Schema" 

    Attribute Key  : "Collection"
    Expected Value : The collection type literal (currently "Array" or
"SetCollection")
    *Note - SetCollection is safer for insuring unique name keys,
although as
    new collection types are added it is really up to the modeling
support.

    Attribute Key  : "Location"
    Expected Value : Qualified path where schema should be stored
    *Note - this is optional, default is ~/.clfw++/schemas/"Name"

    Attribute Key  : "GUID"
    Expected Value : Stringified UniversalIdentifier to be used
    *Note - default is the system will generate, to string up a
    UniversalIdentifier use the UniversalIdentifier::getAsString( buffer
* )
    static method.

with the following attribute keys expected to be supported in later
releases:

     Attribute Key  : "SchemaClass"
     Expected Value : The Schema class type literal to be used when
instantiating
     a new schema, this will be stored with the Schema descriptor and
     will be used when reloading in new sessions.
     Example: "FranksWickedSchemaDerivation"

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package