0.19: Why is there a ID in document object?
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: 0.19: Why is there a ID in document object?
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.
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.
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: 0.19: Why is there a ID in document object?
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 pm 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.
Re: 0.19: Why is there a ID in document object?
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?
I need to think about it more...
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: 0.19: Why is there a ID in document object?
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.
Re: 0.19: Why is there a ID in document object?
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:
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:
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.
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())
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....
Programmers speak by code, in what manner the ID property are troubling you?
Regards
Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
Re: 0.19: Why is there a ID in document object?
Ok, I think I go with just ignoring it and see if some problem comes up.realthunder wrote: ↑Wed Apr 29, 2020 11:21 pm 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.
Re: 0.19: Why is there a ID in document object?
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.
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.
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: 0.19: Why is there a ID in document object?
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
- Veteran
- Posts: 1626
- Joined: Thu Feb 18, 2010 1:07 am
Re: 0.19: Why is there a ID in document object?
Have you tested this? At what threshold is uuid a problem?realthunder wrote: ↑Mon May 04, 2020 11:07 pm UUID is too long, expensive to manipulate comparing to simple integer, ...
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: 0.19: Why is there a ID in document object?
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).tanderson69 wrote: ↑Tue May 05, 2020 3:45 amHave you tested this? At what threshold is uuid a problem?realthunder wrote: ↑Mon May 04, 2020 11:07 pm UUID is too long, expensive to manipulate comparing to simple integer, ...