Re: [UM1-coders] Object Store

[J.P. K. <jp...@he...>]

> (Yes, I'm following up to my own post...)
> 
> Taking a step back, what problem are we trying to solve?
> 
> If we're looking for a secure way of storing the data, then
> this isn't it. It is in-process, and therefore prone to the
> same problems we have already (if we crash unexpectedly the
> data could be in a bad state).

*nod* - but I assume that you can make a separate object store with
this, and then link this, and the original together via a
socket/pipe/rpc/sharedmmap - am I wrong?

This is why you want the abstraction layer, so that you can start
with the code in one place, and then move it around, only needing
to modify the abstraction layer to change where the work happens.

> I think that what we're really after is an out-of-process
> object store that can be connected to by different processes
> (UglyMUG engine, Web interface, low-level db hacking tool)
> at the same time, and provide a minimal amount of consistancy
> (eg no half-written strings, having to use a database snapshot
> from up to an hour ago).

*nod*  This is something that I would consider a vital aim for
some point in the future, yes.

> Admittedly in front of that should be a local-process cache
> that holds some details (the common strings, flags, etc), or
> possibly the whole object, or even depending on what we're
> doing, tell the database how much to cache.

Broadly I consider this to be a detail - an important one, but
a detail none the less.  Given that we don't want to write
our own Object Store we need one which more or less meets our
requirements.

Then we need to make sure that it can be bent enough to exactly
meet our requirements.
Then the work starts.  :-)

Will coldstore be able to replace the current 'object store' that
the game uses?  - If so then it is viable enough to consider.


The consideration needs to include - can we make it a separate
processes to the game engine?  
Do we need write through caching to give us enough speed?  If so
can we implement it with this product?

etc.


I am relatively happy with the idea of moving our current object
store out into a separate process if people think that is a sane
idea - but my impression is that noone had a good opinion of our
DB engine as it stood at the moment.  Is this wrong?

> Adrian.

Julian