[MUD-Dev] Re: atomic functions

[J C Lawrence]

On Thu, 7 May 1998 10:07:39 -0400 
Shawn Halpenny<malachai at iname.com> wrote:

> On Tue, May 05, 1998 at 06:46:58PM -0700, Adam Wiggins wrote:

>> Do an archive search for C&C.  

Ouch.  You are in a maze of twisted piles of messages.  There are many
search hits here.

>> You'll pull up a ton of stuff, probably most of it from JCL.  Then
>> if you have questions/things to add you can do a followup.  We love
>> resurrecting ancient threads here!

> Aye (I had resurrected it that time).  The thread petered out
> eventually after a few of us had tossed about methods for object
> comparison at C&C time, event sequencing, and breaking objects into
> their component attributes for storage.  Above, I'd mentioned JCL
> explicitly since back then he had dropped that he might try such an
> object breakdown and see how it performed.  I suppose we'll have to
> forgive him his day job and wait until he catches up to this
> message.

Originally I based my model on the classical "DB for backing store".
Internal object types at the instance level devolved to flat DB
records with all relationships being virtual and stored within the
record data, not the DB.  This has been a standard approach ever since
UnterMUD, and has been closely followed by the Tiny-* clan, MOO, Cold
etc.

Its not a bad model, but it has limitations.  I'm now using almost a
pure persistant store model.  Persistant store?  Objects are now first
class types that define their own relationships and map directly to
their storage formats.  Little objects, big objects, strings, players,
aggregate objects, nested objects, component objects, transient
objects, etc they're all grist for the mill, and are all persistant.

A side implication of this is that a lot of my DB module has
dissappeared.  The DB module really doesn't habdle persistance and
backing store writes anymore.  All it handles is localised cacheing of 
object contexts for running events (pre-commit).  *Everything* else,
the entire backing store concept, is done by the underlieing and very
well hidden and transparent persistant store.  

Essentially I've created a persistant language, which is a rather odd
thing really.

Gone is the single-file-is-the-world approach.  The DB now spans a
little over a dozen files, each optmising for different object siszes
and base types.  

Good reading on the area:

  Texas Persistant Store
  Arjuna
  Persist++
  ObjectStore

See the FreeDB list for pointers to the above (ObjectStore is commercial).

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...

--
MUD-Dev: Advancing an unrealised future.