* getID(), return object internal identifier. Each object is now
assigned an integer identifier that is unique within its containing
* getObjectByID(), get object by its identifier
From the commit message it's not very clear why this has been added but I think it's to speed up the search for an object. Searching an object by string is much more time intensive than by an integer.Why is that? Did we not have name as a unique identifier?
It's mainly for internal use so you probably won't have to handle it in your code.I'm also interested for what it is used, to see if I need to handle it somehow in my code.
I'm a bit worried, as this ID gets saved in the document file. Hence it seems to be important that the exact number stays the same over file reloads. Maybe it is used somewhere as reference to objects, maybe the links?It's mainly for internal use so you probably won't have to handle it in your code.
So far I have found two places where the id is used. It's in the tree view and for the links. For the former a transient behaviour might be OK but I guess for the latter it's not.Maybe it is used somewhere as reference to objects, maybe the links?
realthunder wrote: ping
The object ID has an important role in my TopoNaming algorithm. The ID is expected to be persistent and unique within the same document.ickby wrote: ↑Tue Apr 28, 2020 2:28 pmI port some custom code from 0.18 to 0.19 rigth know, and detected a difference in the DocumentObject. There is a new ID field in Document Object. Why is that? Did we not have name as a unique identifier?
I'm also interested for what it is used, to see if I need to handle it somehow in my code.
But there is no guarantee of uniqueness in hash. The same goes for option 1, because the ID may have been taken. Can you please explain first what's the intended use of the "exact copy". How are you going to deal with the duplication of name? Are you copying the object into a new document?ickby wrote: ↑Wed Apr 29, 2020 4:31 amok, thanks for the info. That means a object has two unique and persistent identifiers, Name and ID, one string and one int. For my code I need to make exact copies of objects, however, ID cannot be chosen the same way Name can, it is dependent on creation order. I see two solutions:
1. Make ID accessible to the user via the "addObject" function as optional parameter
2. Make the ID dependent on Name: ID == hash(Name)
probability of same hash for different names is "1.0/std::numeric_limits<size_t>::max()" with std::hash, so pretty close to a guarantee.
But than addObject can easily fail with an error.
Yes, i rebuild part of a document in a new one. For that all links and references need to still work. As I not entirely sure how ID is to be used in either your code or any python code out there I need to duplicate it.
Forgot to mention, there is another requirement of ID, that it cannot be reused (within the same document), unlike Name. Because the ID will be used for tracing back model history. If a historical object is deleted, the tracing can continue to the previous step. If the ID can be reused, then the trace may be trapped to the wrong object.
I don't think ID will cause any problem for copying. BTW, maybe you can try the Document.copyObject() API. I have made many changes to make sure the copied object continues to work with all the dependencies, in various use case, like copy objects from multiple documents, copy into the same document, etc. Also with App::Link, it is possible to copy to another document without dependency. It takes quite some effort to make sure everything works, such as expression, spreadsheet, and the need to recompute topo names, etc. There is also the moveObject() API in case you want to move.