The same argument can be applied to Name, as the user may reference the object using a PropertyString. I think that's not really a problem as long as FC can guarantee that copy and paste of objects with dependency works if they are referenced through PropertyLinkBase (which is the base class I added for all link type property, include PropertyExpressionEngine, and PropertySheet). There are lots of internal adjustment going on during copy and paste.Now with the ID this is not possible anymore, if they are used to reference objects anywhere. Hence it is absolutely required to find all objects with references that use the ID, and change them to the ID of the object you want. This is IMHO impossible, as ID is exposed to python and could be used in whatever fancy way the workbench creators can imagine. Just think about storing a ID in a PropertyInt,
How about copying the objects into a new document and then send it over network? In fact FC copyObject() estimate the size of the input objects, and will use a temporary file if it is too big. Maybe we shall expose the exportObjects() API which is used by copyObject() to export to a stream. The exported object (and link property that reference these objects) are saved with a special name, Name@DocumentName, in order to avoid conflict even when exporting objects from multiple documents at the same time (remember App::Link can bring in dependencies from other documents). Then importObjects() can be used to restore from a stream which does the reverse, and auto resolve name conflicts.ickby wrote: ↑Wed Apr 29, 2020 12:43 pmIt's clear that coping and making all links/references work is difficult, I fully agree. Hence I have gone the way to keep all references valid by recreating the referenced objects. E.g. FreeCAD (at least 0.18) stores all links by name in the xmls. So when you access a object with the "Content" attribute you see all references by name. That object can than easily be restored in a new instance and everything works perfectly as long as the linked object with given name exists.
No, a name can be recreated in the new doc, hence every Name stored in PropertyString stays valid. ID cannot be recreated. At least for my use case this is a difference.The same argument can be applied to Name, as the user may reference the object using a PropertyString.
No, this does not fit my use case.How about copying the objects into a new document and then send it over network?
But you'll still need to worry about name confliction if the document receiving the objects already has some existing objects around, unless your operation is restricted for a brand new document, and can be applied once and only once, in which case you might as well save the objects to a new document and call it a day.
Code: Select all
working_objects = for obj in DOC,Objects: working_objects(obj.copy())
Code: Select all
working_objects = for obj in DOC.Objects: if obj.PN = > 10000 working_objects.append(obj.ID) for part in working_objects: obj = DOC.ObjectsbyID(part) obj,Plaecement....
UUID is too long, expensive to manipulate comparing to simple integer, and most importantly, not unique at all, considering the user is free to duplicate the document and then copy object back and forth.
Not really 'a problem', it's just that it has extra overhead but no real benefit in this particular use case (i.e. for my topo naming algorithm).