>
> 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?
>

AFAIK yes. In any case the {x...} locations are changed by the remote
functionality to avoid clashes with local objects, ie a remote object won't
have the same {x...} as it has locally on the remote machine.

This fact could be used in the creation of functions that handle remote
objects more or less transparently, a typical example would the the get
algo, let's say I do (;; Trans user) and Trans is a remote object then the
;; function infers that fact and fetches the user from the remote machine
through the local +Link pointer on that machine.




On Mon, Jan 27, 2014 at 3:16 PM, Thorsten Jolitz <tjol...@gmail.com> wrote:

> Henrik Sarvell <hsarv...@gmail.com>
> writes:
>
> Hi Henrik,
>
> > why do you want to do this explicitly since it's done for
> > you implicitly in all the various type of reference relations you have
> > (typically +Link)?
>
> 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.
>
> > In Macropis I simply use the convention of having a relation called id
> > auto increment (by way of http://software-lab.de/doc/refG.html#genKey )
> > , that way it doesn't matter which machine something is on, I will
> > never have to worry since something like the action /+Page/update/3/
> > always updates the object of class +Page with id 3 no matter what the
> > {x...} location might look like.
>
> 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?
>
> > However the impetus for this convention was actually the fact that
> > functions like db and collect need for instance a +Ref or +Key to be
> > able to fetch an object at all, having a +Key called id in all objects
> > make things so much easier.
>
> I figured that out too (-> db and collect need a +Ref or +Key) and it
> makes using a +Key id even more reasonable, I wasn't aware of the id
> functions in picolisp, so I thought about my own solution.
>
> > But anyway, to really answer your question you might want to look
> > into: http://software-lab.de/doc/refI.html#id
> >
> > And as far as the remote stuff goes with the db id and obj id combo
> > AFAIK you have to implement it yourself, you might want to start by
> > reading this discussion:
> > http://comments.gmane.org/gmane.lisp.picolisp.general/2849
>
> Thanks for the tips, very helpful!
>
>
> > On Sun, Jan 26, 2014 at 6:56 PM, Thorsten Jolitz
> > <tjol...@gmail.com> wrote:
> >
> >     Thorsten Jolitz <tjol...@gmail.com>
> >     writes:
> >
> >     ,------------------------------------------------------------------
> >     -------
> >     | Sorry, I sent this post accidentally before I was finished, so I
> >     have to
> >     | send it again.
> >     `------------------------------------------------------------------
> >     -------
> >
> >
> >
> >     Hi List,
> >
> >     say I want to use the internal Object ID of database object as a
> >     unique string
> >     identifier (useful e.g. for export in a textformat), i.e.
> >     something
> >     like:
> >
> >
> >     ,-------------------------
> >
> >     | : (put '{33} 'ID "{33}")
> >
> >     `-------------------------
> >
> >     how do I get the ID from a database object in a program? And is
> >     there
> >     some unique identifier for a database too, so that object-id and
> >     db-id
> >     could be combined into a globally unique id?
> >
> >
> >
> >
> >     --
> >     cheers,
> >     Thorsten
> >
> >     --
> >     UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> >
> >
> >
>
> --
> cheers,
> Thorsten
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Reply via email to