[MUD-Dev] Re: Databases: was Re: skill system

[Jon A. Lambert]

Merged several messages together here. :)

On 26 Jun 98, J C Lawrence wrote:
> On Sat, 20 Jun 1998 04:17:25 -5 
> Jon A Lambert<jlsysinc at ix.netcom.com> wrote:
> 
> > RDBs are ideal for mapping objects with static runtime attributes.
> > In order to succesfully map an object with dynamic runtime
> > attributes to an RDB, the object must be reflective.  That is it
> > must be at all times self-aware of it's attributes.  In addition
> > the RDB ideally is designed in such a way as to implement object
> > reflectivity instead of the object directly.  This requires an
> > interface or translator module.  One can certainly map an object
> > directly to an RDB using what static properties are known to all
> > objects and putting the dynamic properties into a binary blob.
> > This is quite similar to the conventional use of dbm and related
> > implementations.  
> 
> Quite, and is so far the approach I am considering taking.  While
> I'm not entirely clear on your use and definition for "reflective"
> and "self-aware" above (please expound), your mention of a
> translator module would seem to suggest that you are looking at the
> same type of model I am: various meta tables (mostly containing the
> names of other tables) which are used to define the structural
> relationships and their significance between the tables.

Err, rather the RDB should be reflective of the softcode OO model, 
not the object itself. 

In a static model, the RDB is reflective of the actual objects.  For
instance, class Room maps to table Room and object instances of Room
map to rows of table Room.  One-to-one and one-to-many associations
between instances of Room and other classes like Exits or Persons are
mapped to columns which are foriegn keys into the Exit or Person
tables.  Inheritence can be mapped in almost the same way, although it
is interpreted differently.   The database is a direct mapping of the
objects and their relationships.  It is reflective of the application
intent of the objects.

All of this is quite useless in a dynamic model.   But instead of even
attempting to map mud objects directly, one might do better in mapping
the abstract softcode OO model.  Just as most rdbms contain system
tables that describe a relational model of themselves, one can create
tables that contain a relational model of a OO model.  Just as UML can
create an object model of an application, it can also be used to
diagram an object model of UML itself.   Um, perhaps this analogous to
compilers that will compile themselves.

With this in mind:

Classes have 0 or more Parent classes.
Classes contain 0 or more Object Instances.
Objects Instances contain 0 or more Attributes.
All Objects have OIDs.
All Classes have names.
...and so on..

Map the abstraction relationally instead. :)


> On  1 Jul 98, J C Lawrence wrote:
> On Tue, 30 Jun 1998 02:57:01 -5 
> Jon A Lambert<jlsysinc at ix.netcom.com> wrote:
> 
> > On 25 Jun 98, J C Lawrence wrote:
> >> On Thu, 25 Jun 1998, Jon A Lambert wrote:
> 
> 
> So far I've been very effective in convincing myself that an SQL
> base is not well suited for a runtime morphic and irregularly
> patterned (at least as a class heirarchy) MUD.

Right.  Then again the same problems rear there ugly heads in using
OODBMSs.  Most of these critters are as static as RDBMSs.  Runtime 
dynamism is rather unique to our problem.  I don't believe many 
persistent storage mechanisms even recognize runtime dynamism.  A 
good place to look for mechanisms may well be in Smalltalk 
literature.      

> > Although I cannot fathom a mud having 1000+ tables.  
[snip]
> 
> Think one table per object class and a fairly well developed object
> heirarchy (free user programming).

Nod. This is exactly why traditional methods of OO to relational 
mapping will not work.  There's quite a few "patterns" out there, but 
I have not seen this problem addressed.
 
> > Construct an abstract object model of the object model that the
> > softcode follows.  Even if you not using relational technology, I
> > think this is the way to go.  
> 
> Already done.  Thus the map for ObjectID to method list, to
> containment directives list etc.  The structure is actually very
> simple: just four lists (of lists) with an ObhectID tag at the top.

That's where I started.  The only problems come at the point
where dynamic primitives (attributes) are mapped.  They can
be mapped to separate tables by type or to a single table with 
columns for each possible primitive and typing information.  
Either approach makes adhoc native SQL querying more difficult.
Unless you've constructed a query interface that filters attribute 
typing information. :) 

> > How many OO-DBMS's or P-Store systems follow your softcode OO
> > model? Probably none, right!?
> 
> I can't comment on the OODBMS end, but that's *exactly* what
> persistent stores do.  At an idealised level a persistant store is
> rolled into code as follows:
> 
>   class persistent bubba {
>     public:
>       lotsa methods();
>     private:
>       lotsa more_methods();
>   };
>     
> After that all instances of the bubba class are automagically
> persistent, and by their very nature follow your internal model as
> that's what your code-model follows (doesn't it?).  Ideally you
> never see or care about the storage format, indexes, record types,
> tables, joins, inserts, etc.  You just behave as if you had
> unlimited battery-backed RAM.  The peristent store merely adds a new
> flavour modifier to the volatile/automatic/static/const set.

Yes, but they are not runtime dynamic.   Classes/Object attributes 
are fixed at compile time.  :(

> > Perhaps we should be discussing softcode OO models rather than DB
> > implementations.  Is the softcode-OO-model like Java, C++, ColdC,
> > LPC, etc.?  Single or Multi inheritence?  Is there a distintion
> > between object and class?  Are inheritence and attributes dynamic?
> > Are there built-in or native objects?
> 
> The OO model is rather ColdC-like (slightly Python-ish but not
> quite), with multiple inheritance, clear seperation between
> definition and instance (object and class), with inheritance and
> attributes being dynamic.  There are a variety of primitive native
> objects and (currently) no ability to create ad-hoc ADT's (alas).

Do you have singleton instances of class objects, like C++?
Do attributes and method code reside in the class, object or both?   

My model closely reflects C++.  However all inheritence is private 
and thus the softcode model strongly favors composition and 
delegation over inheritance.  Methods and attributes can reside 
both in class instances and in object instances (aka C++ "static").
My native objects could best be described as Java interfaces or
COM objects but they cannot be inherited.  

> > What you (and I) are doing is really designing the architecture of
> > an OO-DBMS.
> 
> <sigh>
> 

<insane cackling>

  
--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--