Thu, 04/13/2017 - 12:29
Hi,
I have been using OCAF for quite a long time with own specific attributes that I have created by subclassing TDF_Attribute. For these attributes I have created attribute drivers by subclassing BinMDF_ADriver. But what about changes in the data model? Attributes of some newer document versions may contain more data. This I have handled by writing/reading Standard_Booleans to/from BinObjMgt_Persistent to signal whether the additional data of newer document versions is present or not. It works.
But does the framework offer something to support different versions of TDF_Attributes? In XmlOcaf (which I do not use) I have found some version information. What about BinOcaf? Did I miss it or is it not there? What is the recommended way for dealing with different document versions with BinOcaf?
Thank you very much,
Benjamin
Tue, 05/16/2017 - 18:15
Dear Benjamin,
Analogically to Xml format Binary format manages versions via Document services.
The Unit BinLDrivers contains all necessary API (CheckDocumentVersion(),PropagateDocumentVersion(),StorageVersion()..).
Best regards,
Forum supervisor
Tue, 06/13/2017 - 13:18
Hi!
Thanks for that answer, I had overlooked these methods.
Still I wonder whether this is exactly what the users need. The methods you have mentioned, handle a OCCT document version, which is compiled into the OCCT libraries (CURRENT_DOCUMENT_VERSION in BinLDrivers.cxx) and it allows distinction of versions of the default attribute drivers. Isn't this the purpose?
But let's assume I have MyApplication 1.0 with an old version of my TDF_Attribute/BinMDF_ADriver subclasses and MyApplication 2.0 with a new version of these subclasses. Both applications might link against the same version of OCCT having therefore the same CURRENT_DOCUMENT_VERSION. Should I really try to open up the OCCT document version methods for being able to distinguish my application versions? Or should I use another mechanism?
I have found out that Storage_HeaderData contains an application name and an application version. Actually this seems to be perfectly suited to distinguish my data model versions. Yet it seems as if these entries are always empty when storing binary files (around line 407 of BinLDrivers_DocumentStorageDriver.cxx a new instance of Storage_Data is created, which contains the header data and the respective entries are never filled with anything meaningful before writing them in line 430). Have I again missed something? Or is this an incomplete feature which might be fixed and used for data model distinction?
Thank you very much for your input!
Benjamin