Hi Thorsten,
> 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.
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.
A typical export function for a database looks like
(de dumpMyDB ()
(out "myDB.l"
(prinl "# " (stamp))
(prinl)
(prinl "# Roles")
(dump (db nm +Role @@))
(println '(commit))
(prinl)
(prinl "# User")
(dump (db nm +User @@))
(println '(commit))
(prinl)
(prinl "# Shops")
(dump (db id +Shop @@))
(println '(commit))
... )
(when (dir (tmp))
(out "myDB.tgz"
(chdir (tmp)
(in (append '("tar" "cfz" "-") @)
(echo) ) ) ) ) )
(de loadMyDB ()
(when (and (info "myDB.tgz") (n0 (car @)))
(in "myDB.tgz"
(chdir (tmp)
(out '("tar" "xfz" "-")
(echo) ) ) ) )
(load "myDB.l") )
'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.
♪♪♫ Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
