[Coldstuff] SQL...

[Brad Roberts]

> I'm perfectly certain that it won't even perform close to the current
> configuration.

I'm ignoring the rest of the post and concentrating one this piece, in
case anyone has the desire to try it accidentally.  Without the caching,
you'd have two basic choices:

a) super fine grained and thus the slowest version

  begin transaction

  select blob from table where id=objnum for update

  unserialize

  change variable/method/whatever tiny piece

  serialize

  update table set blob=newblob where id=objnum

  end transaction

b) or less fine grained

  in vm_task

  begin transaction

  for each object_retrieve add to a list of retrieved objects

  update each as needed until getting to the end of the task

  traverse the list serializing and updating the db

  end transaction

I have to rule (a) out as just unreasonably slow.  In (b), you'd still have
a cache of some sort, since objects would stay for at least a short
time frame (far far far shorter than in the existing code).  I haven't
bothered to try b, though I did consider it briefly in a fit of insanity a
while back (at least 3 years ago now). I actually did write a sql layer to
replace the binarydb and lookup layers, definitely not taking any real
advantage of the engine.  It wasn't too bad, since the cache still existed
to insulate the speed hit.

Going back to the original question, I don't know if any of this has
actually helped answer the question.  None of the stuff presented so far
will give genesis or coldcore the magical ability for a user on one
instance (assuming that multiple instances is achievable in the first
place with any of the proposed sql or binarydb layer changes) to say "hi"
to another user connected to another instance since that sort of data
isn't passed through the database, its done directly from connection
object to connection object in coldcore.

Edward, has any of this helped or just confused?  If not, can you
elaborate on what you're trying to accomplish and guide this discussion a
little better?

Later,
Brad