Moi,

so what I'm trying to achieve is probably best explained by code. 
Purple.add  is a function that takes any object, saves it and returns a 
unique database id. Purple.get takes such an id and returns an object 
that is data-wise quivalent to the original.
What I'm trying to do boils down to returning the _same_ (===) object 
that was put in, if it's still around. For that I need some kind of id 
system. But first, in code:
a = "rubies can have a shade of purple"
b = [ a ]
id_a = Purple.add a
id_b = Purple.add b
// commit ... ...time passing ... id's get passed around the net and 
come back, then ..
aa = Purple.get id_a
bb = Purple.get id_b

aa === bb.first  // that's what I want, just == I can already do, but 
for graphs that's no good.

So I looked at the ruby id related functions. Is it true
-- Basic types (symbols, strings) have id's that count up, the id is 
never reused
-- objects use their address as base for id
-- thus if an object goes out of scope and the memory is reused, i can 
later have a different object with the same id

And how are id's for more complex, but builtin types done ? I mean 
array, hash, bignum, regex ...

So coming back to my problem, does it sound like a solution that in add, 
i add my db_id to objects (**), and store a mapping of the ruby_id 
against my db_id for basic types. And then in the get, I check if the 
object has a db_id, in which case I have to do nothing, and for basic 
types I check my mapping and return what I find, or I instantiate the 
say string, and store the mapping again. Does that sound reasonable ?

Cheers
    Torsten