Dear Brian,
Do you mean the StructureEnsemble.ensembleId?
I would recommend the same behaviour that we use for .serial attributes:
new serials start at the highest current serial + 1. So, if you have
objects with serials 2, 5, 11, the next objects gets serial 12. In this
way serials tend to be predictable and increasing over time. Of course if
you delete the most recent objects, the serials will get re-used after
save, quit, and re-start. This is not perfect, but allowing that little
wart saves you from saving the last used serial explicitly.
Yours,
Rasmus
---------------------------------------------------------------------------
Dr. Rasmus H. Fogh Email: [log in to unmask]
Dept. of Biochemistry, University of Cambridge,
80 Tennis Court Road, Cambridge CB2 1GA, UK. FAX (01223)766002
On Wed, 18 Feb 2009, [ISO-8859-1] Brian Smith wrote:
> So, a little warning with this. We're using ARIA v2 with it writing
> structures & restraints back into the CCPN project. When we delete some of
> the early .xml coordinate files, ARIA starts putting new structures in
> numbering them again serially from 1. This can lead to a little confusion
> when you're trying to work out what you can and can't delete. I can't quite
> work out whether the internal serial identifier gets reused or remains
> unique - I imagine the intention is that it should remain unique.
>
> On Wed, 4 Feb 2009 10:28:45 +0000, Rasmus Fogh <[log in to unmask]> wrote:
>
> >In v1 you are perfectly safe in deleting files on disk that are no longer
> >referenced by the remaining XML.
>
> >> In v1.0.15 deleting a
> >> structure doesn't seem to purge the coordinate .xml file - over the
> >> lifetime of a set of structure calculations the project grows a lot. I
> >> think the coord files are dereferecend in the rest of the xml code, so I
> >> guess it should be OK to delete the superfluos ones by hand (should be
> >> simple enough from the sequential numbering)?
>
|