View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0028792 | Open CASCADE | OCCT:Application Framework | public | 2017-05-26 15:15 | 2017-05-26 15:16 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | feature | ||
| Status | new | Resolution | open | ||
| Product Version | 7.1.0 | ||||
| Target Version | Unscheduled | ||||
| Summary | 0028792: Identification of an attribute at label by a custom GUID or string | ||||
| Description | TO ALLOW SETTING DIFFERENT GUIDS TO ATTRIBUTES OF THE SAME TYPE The origin of this approach already exists in OCAF: TDataStd_UAttribute and TDataStd_TreeNode. It allows keeping several attributes of this type on the same label with user-defined GUID identifiers. It is proposed to implement the same possibility for all attributes on the basis level (TDF_Attribute). For an example, TDataStd_Real could use the following syntax to set attribute to the given label: #define DENSITY Standard_GUID("12e9454b-6dbc-11d4-b9c8-0060b0ee2810") #define VOLUME Standard_GUID("12e9454b-6dbc-11d4-b9c8-0060b0ee2811") TDF_Label aLabel; TDataStd_Real::Set(aLabel, 1.1); // the current API TDataStd_Real::Set(aLabel, DENSITY, 1.2);// same attribute type, special GUID TDataStd_Real::Set(aLabel, VOLUME, 1.3); // same attribute type, special GUID So, Real will have two fields: GUID and Value and it is possible to have many attributes containing real value on the same label. If, as currently, special GUID is not set, then default (used currently) GUID is used and in the document this GUID is not stored (as it is done today for TDataStd_TreeNode). So, this approach allows keeping backward and forwarding compatibility of the API and documents stored. TO IDENTIFY AN ATTRIBUTE BY A STRING Attributes of one kind may be distinguished by the additional string-identifier. Attributes also will be identified by GUID (also it is possible to use the approach above: many GUIDs for popular attributes types). By default this identifier string is empty, so it will look similarly to the present OCAF approach. For an example, in addition to: aLab.FindAttribute(TDataStd_Real::GUID(), aReal) there could be: aLab.FindAttribute(TDataStd_Real::GUID(), "density", aReal); or aLab.FindAttribute("density", aReal); In the last case there must be one attribute on the label with "density" identifier (in paractice it is the same as default GUID is used). To set attribute an additional method must be added: TDataStd_Real::Set(aLabel, “density”, 1.1); So, it is universal modification that will be applied to all attributes. This requires modification of OCAF core: TDF_Label and TDF_LabelNode with changes in persistence drivers. Also all “Set” methods of attributes must be extended to set string-ids. Nevertheless it will allow keeping the forward and backward compatibility with documents that are not use string identifiers. Without additional identifiers (or empty strings), attributes will be stored in the document as it is done before. TO IMPROVE AN ACCESS TO ATTRIBUTES With implementation of abilities to put many attributes to one label, the problem of slow access to each attribute is appeared. Currently all attributes are located in LabelNode as a list. So, access time depends on the number of attribute in this list. It is proposed to use specialized DataMap to store attributes and provide fast access by hybrid hash-code GUID+string id. This specialized DataMap must spend minimum memory in case only few attributes are stored (still must be just a list for 1 or 2 attributes). The general number of attributes still remains very low, but number of labels in the document may be huge. The used number of buckets must be less than the number of elements (the real dependency will be investigated during the implementation). This task concerns only internal implementation of LabelNode. So, no changes in used API or formats compatibility are expected. | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
