[REBOL] Re: possible data format ... Re: Re: dbms3.r 01
From: petr:krenzelok:trz:cz at: 16-Jan-2002 9:48
Hi,
Gregg Irwin wrote:
> Hi Pekr,
>
> << a) now I am not sure if locking should happen on index level (dangerous
> if someone
> will not use any index), or in database itself ...
> b) if we have no db server and our app fails, record would stay locked
> forever, so we
> would have to complicate things with some time-stamps or so ...>>
>
> If we don't have a central server script, there has to be some kind of lock
> publishing mechanism. The easiest way, perhaps the only feasible way, is to
> use a persistent marker as you suggest.
Maybe I don't think so anymore :-) I talked the problem with my colleagues here,
and Michael suggested, that any kind of locking, is done in memory. We found one
interesting document though, which describes several scenarios, even one with
lock field and time stamp ....
http://www.rebol.cz/~asko/xbase.txt - very cool description ....
> In order to unlock a frozen lock you
> need a manual unlock feature, or a timeout specified for each lock. If you
> go the timeout route, you may want to implement some kind of time-extension
> callback feature so you can be notified if a lock you hold is going to
> expire, with the option to hold on to it.
yes, it could work, although it would require e.g. your form to have some timer
implemented ...
> The manual unlock approach is
> probably simpler, but not nearly as slick and not suitable for unattended
> use.
>
uhmm, not this one probably :-)
> << - record-numbers - I hope it is clear enough, that 'pack-ing the database
> will reassign
> record numbers to remove holes caused by record deletion ... >>
>
> I thought the intent was to assign a UUID to each record, which it would use
> forever, so location was not important.
in XBase, it has its meaning. You can open dbase file without opening any index,
so browser sorts records according to their rec-no.
> << - variable record size - a block. OK - how will we map it to any rebol
> structure/object? I just hope that at least that number of columns are the
> same thru
> all records or I can't imagine it in other way than duplicating column names
> in each
> record, e.g. [name: "pekr" lastname: "krenzelok"], which is not good aproach
> to follow
> imo? >>
>
> I don't like wasting space any more than the next guy, but I *love*
> self-describing data. Since we're targeting small to moderate size data
> stores, I wouldn't be opposed to blocks of name/value pairs. If we load a
> large block of records which share common words as their column names, REBOL
> should handle that very efficiently, correct?
I think that it depends upon what your intention is - do you want to have
variable column records? I would not suggest it, as it is a little bit more
difficult for any kind of anylysing software, which simply counts something in a
loop ....
I would suggest:
rec-no ["various" 3 'or [more--datatypes]] ["D" time-stam-of-creation last-changed
[locked-time-stamp user-info whatever]]
above structure only shows aproach I would go with - first info, 'selecta-ble or
'find-able record-number, then record itself, followed with third block
containing some system info - navigation is pretty straightforward, and we could
use wrapper functions
get-lock-stamp: func [db rec-no][first last last next next find blk 5] , where 5
= rec-no :-)
-pekr-
