0.19: Why is there a ID in document object?

[ickby]

Ok, to not be reusable makes it a bit harder. I also cannot use the FreeCAD APIs, as the rebuild happens in a different FreeCAD instance, connected over network.

It'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. 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,

IMHO it makes sense to allow the user full control over Object identity, as it was with 0.18. A possible option would be the exposing to addObject and failing if such a object already exists or was used before.

[realthunder]

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,

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.

It'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.

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]

The same argument can be applied to Name, as the user may reference the object using a PropertyString.

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.

How about copying the objects into a new document and then send it over network?

No, this does not fit my use case.

I need to think about it more...

[realthunder]

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.

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.

Another thing to note is that addObject() will auto rename to avoid conflict, so the input Name is basically just a suggestion. I can probably add a new argument to addObject for ID suggestion, but it will be less useful because of the reusable restriction. Currently, the code uses a monotonically increasing integer to generate the ID. So for example, with your operation, you'll have to sort the objects by ID before adding.

Anyway, like I said in my previous post, object ID is not meant for direct referencing. I wouldn't worry too much about it when copy and paste.

[onekk]

Speaking from another point of view, maybe if i use FreeCAD in a working environment maybe a property that i could use to store some "Part Number" or "Product ID" maybe be useful, from the point of view of maybe of the "production manager" but for the point of view of the designer maybe it is not a great requirement.

So what are you trying to achieve is more interesting over other philosophical thinking.

If you see it from a "programmer point of view" "obj" has to be everytime "obj" except if you wanto to change it, if it is a compound if i do
obj.copy() generally or maybe i will do:

Code: Select all

working_objects =[]

for obj in DOC,Objects:
	working_objects(obj.copy())

from this point how i use this working_objects are not a concerns of the maker of the software, the only thing I could ask the creator is that these objects are copied in a exact way.

If the software for his internal behaviour has to use the ID property, it will make it read_only and manage it for his "internal scopes", it's not my care.

suppose you have a PN (Product Number) property and you want to achieve some operation on the PN > 10000 whatever that is meaning

if a program permit me to do:

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....

And maybe this is more fast than copying the objects directly, i will be more happy than having to retain this ID across copy.

Programmers speak by code, in what manner the ID property are troubling you?

Regards

Carlo D.

[ickby]

Anyway, like I said in my previous post, object ID is not meant for direct referencing. I wouldn't worry too much about it when copy and paste.

Ok, I think I go with just ignoring it and see if some problem comes up.

[triplus]

In my opinion each document object should have an UUID assigned and that would i guess be that.

P.S. Relying on things like "internal name" or a "(short) integer", that i guess is just not unique enough, to be all that reliable.

[realthunder]

In my opinion each document object should have an UUID assigned and that would i guess be that.

P.S. Relying on things like "internal name" or a "(short) integer", that i guess is just not unique enough, to be all that reliable.

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.

[tanderson69]

UUID is too long, expensive to manipulate comparing to simple integer, ...

Have you tested this? At what threshold is uuid a problem?

[realthunder]

UUID is too long, expensive to manipulate comparing to simple integer, ...

Have you tested this? At what threshold is uuid a problem?

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).