Alexander Burger <> writes:

Hi Alex,

>> I want to export the objects to a textual representation that might be
>> edited and then committed again, so I must be able to find out which DB
>> object is associated to the textual representation. 
> Note that in general it is not recommended to access external objects by
> their name.
> It is true that you can easily write it to a file, simply with 'print',
>    (print '{33})
> and you can also 'read' it back again.
> The problem is that {33} might meanwhile be deleted from the DB, i.e.
> the block at offset 33 is returned to the free list, and reading and
> accessing this object would result in a runtime error. Or, even worse,
> this block may be re-used by some completely different object.
> Therefore, as Henrik pointed out, portable access to database objects is
> only meaningful via their index keys.

Yes, I think what Henrik uses is a good and simple solution.

> Concerning you intention to export objects to an editable
> representation:
> There is a 'dump' function exactly for that purpose. It writes arbitrary
> Pilog selections to the current output channel.
> Taking the salutations from demo 'app' as an example
> : (load "@lib/too.l")
> : (dump (db nm +Sal @@))
>    ...
>    (obj ((+Sal) nm "Herr")
>       sex T
>       hi "Sehr geehrter Herr @1," )
>    (obj ((+Sal) nm "Herr Dr.")
>       sex T
>       hi "Sehr geehrter Herr Dr. @1," )
>    (obj ((+Sal) nm "Mr.")
>       sex T
>       hi "Dear Mr. @1," )
>    (obj ((+Sal) nm "Mrs.")
>       sex 0
>       hi "Dear Mrs. @1," )
>    ...
> As you see, this is a format which can directly be 'load'ed.

Another very useful function in PicoLisp! Although in my case I need a
special syntax for the textual representation, and I think its easier to
build that syntax by getting the info from the DB objects than to parse
and modify the dumped DB.

> A typical export function for a database looks like
>    (de dumpMyDB ()
>    (de loadMyDB ()
> 'dump' also takes care of related data blobs. In the above example, all
> (the 'load'able file and the blobs) are all packed into a single TGZ
> file.


>> That sounds like a solution I should copy. Just out of curiosity: in a
>> distributed database, the object ids ({3}, {1-2} ...) are not unique but
>> might be repeated on different machines?
> Right. The combination "file" and "offset", which specifies a given
> object, may appear on remote machines again. But there is no problem as
> long as you use indexes to access the objects.

Ok, thanks



Reply via email to