[MUD-Dev] Re: [DevMUD] Re: From Devmud: Database module, draft 3

[Greg Connor]

> > = [Greg Connor:]
> >This was because db_direct_writeable_record gives you a writeable record,
> >but doesn't actually "write" to the database until you release it, so
> >"write" might be misleading.  The closest action word is probably "get" ..
> >I think I had that in there and took it out to shorten it a bit :)
>
> = Chris Gray wrote:
>Hmm. OK. The consistency and clarity of the naming does suffer a bit,
>however. Even though I dislike long names, I'm tempted to suggest
>putting the 'get' and 'put' back.


You're probably right... why save a few characters at the expense of
clarity? :)


> >[when getting fields one at a time...]
> >A lock would be useful to the client, but I'm still going to try to weasel
> >out of implementing one.  What if you could mark several fields that you
> >want to fetch (like setting a flag in the db_record header) and sumbit one
> >call to get them all?  This might save some overhead too, for network
> >sources.
>
>That would work. Some solution is needed here, and I understand your
>reluctance to require locking. Locks bring up the whole question of
>how you make someone wait on a lock - sounds like you need a spec
>for a core-provided threading package, at least a wait-for-lock entry
>(which should always just return in a non-threaded server).


You're right, I hadn't thought about the locks that much.  Locks and
threading would probably add up to trouble.  I'll enable multiple things to
be fetched at once and keep "lock" out of the interface for now.


In the direct mode, where I have a lock/release defined, it's not designed
for threading, just to keep you from doing something silly, so returning
with an error would be appropriate.  If your server is single-threaded, not
much sense calling wait()...

I am probably going to move the direct mode calls to the "not now,
investigate for version 2" list.  I dread the thought of implementing locks
if they're only going to be used as an optimization (and a dubious one) and
limited to single-threads.  I will probably have a better feeling for
whether this is needed when the prototype method-2 only version can be tested.


> >Db_record (the structure) is what you said second: address/length pairs
> >(possibly some flags to go with each field, like whether it is loaded,
> >null, requesting to be read, requesting to be written, etc).. It is only
> >variable in size to the extent that you will add or remove fields.  
>
>Ah, ok. So, db_get_record_header_size says how big the db_record
>structure for that record will be and db_get_record_header copies the
>struct in. Given that, why does one need db_get_field_size? If the
>user is to be able to examine/set flags per field, then the contents
>of a db_record are public. It could be implemented as a macro, but a
>call to it will be longer than just grabbing the length directly.


You're right.. I had "get_field_size" in there for symmetry but it isn't
really needed.  db_record should be a public structure type... it might
have some fields that only make sense to dbmodule itself (like revision
info or some other cookie to validate write-back changes) but I think that
won't bother things much.  So strike the "get_field_size".

Size info might be out of date if someone else modified the record between
one fetch and the next, but in this case you would get a "not big enough"
error and realloc/try again.  There should be a call to refresh the header
(maybe just calling get with no fields marked would do this).

Thanks for the feedback.  I'll revise the spec again this week or this
weekend with the changes to date.  I may even get to write some code this
weekend (er, if header files count :)