Immutability of data referenced by Ids (semantics of deletion/recycling)
Page 1 of 1
Immutability of data referenced by Ids (semantics of deletion/recycling)
When accessing data (solvers, jobs, job pairs) programmatically, Ids are used. What guarantees are there about immutability of the objects referenced by these Ids?
Is it possible at all to re-use an Id, e.g. it denotes one solver at one time, but another solver later? I hope not. But then what is this "recycling" stuff? Is this some kind of garbage collection for resources? I think deletion is fine, but re-use of Ids is not. You do have enough Ids? (how many bits are they?)
For solvers, we also need configurations. A configuration can be overwritten? (Does it change the Id?)
For each job pair, the status goes from pending to enqueued to ... to completed (?) and then the contents is immutable?
Is it possible at all to re-use an Id, e.g. it denotes one solver at one time, but another solver later? I hope not. But then what is this "recycling" stuff? Is this some kind of garbage collection for resources? I think deletion is fine, but re-use of Ids is not. You do have enough Ids? (how many bits are they?)
For solvers, we also need configurations. A configuration can be overwritten? (Does it change the Id?)
For each job pair, the status goes from pending to enqueued to ... to completed (?) and then the contents is immutable?
j.waldmann- Posts : 84
Join date : 2014-04-26
Similar topics
» no "recycling" for things that are still referenced
» What is the semantics of "subspace summaries" and "graphs"?
» please clarify: how long do you (intend to) keep job data?
» What is the semantics of "subspace summaries" and "graphs"?
» please clarify: how long do you (intend to) keep job data?
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum