 |
Archives |
Archives
| <<< Partitions and Rollback | Chapters | Assemblies and Instances >>> |
Parasolid archives are intended to fit into an archiving system within the application. This could take the form of a controlled directory structure on the host computer, or some kind of database. The nature of this storage depends on the application's Frustrum.
Parasolid does not provide any means of deleting parts from archive, or listing keys which have been used to archive parts, either in the current session or in previous sessions. The application must keep track of the keys used. The Frustrum should also trap attempts to write new archive data to a file which already exists (i.e. re-use of keys).
See Chapter 2, "File Handling", of the Parasolid Downward Interfaces manual for further information about the Frustrum functions required to implement archiving.
See Chapter 43, "Assemblies and Instances", for further information on the use of assemblies in archiving.
To save or write data from Parasolid to an external store is referred to as transmit.
To load or read data from an external source into the current Parasolid session is to receive.
PK_PART_transmit transmits one or more parts to a logical file through the Frustrum. The application provides a key string, which the Frustrum may use, for example, as a file-name or an index into a database:
There are five formats that can be used for the archive, which should be provided in the application Frustrum as required.
| Format | Frustrum requirements |
|---|---|
|
these three use the FFOPWR frustrum function, or the UCOPWR frustrum function if it is defined. |
|
|
this format uses the application frustrum functions which are registered by PK_SESSION_register_applio |
For further information about transmit formats see Chapter 2, "File Handling", of the Parasolid Downward Interfaces manual.
A part may be transmitted so that it can be received by a version of Parasolid earlier than the current version (the version doing the transmitting).
This means that parts modeled in the current version of Parasolid can also be archived in any format from V7 onward, and thereafter received by an application using that earlier version of Parasolid.
The required version is specified in PK_PART_transmit_o_t.
|
Note: If saving a part in a format earlier than Parasolid V12.1, the part must not contain certain non-printing characters, such as carriage return and linefeed, in attribute string fields. Attempting to save a part containing such characters raises the error PK_ERROR_bad_text_conversion in the call to PK_PART_transmit. Parts saved in Parasolid V12.1 format or later can contain these non-printing characters, and no error is raised. |
When a part is archived, the following items are saved:
Identifiers are integer values which are attached to all entities within a part, except for fins and the part itself. The identifiers within a part are distinct. Unlike tags, they are saved when a part is archived, so identifiers can be stored with a part key in an external database to keep a handle on a particular entity.
There is no guarantee that the same entities have the same tags when loaded into another session. The decision as to whether the application uses identifiers depends upon whether it needs to reference entities within archived parts in different modeling sessions.
When a part is archived, the application must use PK_ENTITY_ask_identifier to record the identifiers of entities it wishes to access in a new session.
When the part is retrieved, PK_PART_find_entity_by_ident is used to get the new tags of required entities.
| Tags | Identifiers | |
|---|---|---|
| Uniqueness: | ||
| Result when a part is archived: | ||
| Result when a part is changed: | ||
| Effect between sessions: |
* caution must be applied as a change of tag could appear to occur when an entity is replaced by a similar entity
PK_PART_receive receives one or more parts from a logical file through the Frustrum, using the key string given by the application:
It is the application's responsibility to ensure that Parasolid can find the archive data for the part. This is mostly dependent on the Frustrum. If the key cannot be found by the Frustrum (for instance because it simply treats keys as filenames and has no information on which directory to look in) then PK_PART_receive fails.
The kernel's ability to receive a part also depends on which version of Parasolid saved it. A part is saved with a reference to a specific Parasolid schema file. Once the application has used more than one version of the kernel, the Frustrum must retain schema files for each version, or else the application is unable to receive old parts.
To receive user fields archived with the entities of a part, the length of the archived user fields must be the same as, or shorter than, that set for the current session by PK_SESSION_start.
If they are not, PK_PART_receive can be prevented from trying to read them by setting the option
receive_user_fields
to false. This causes Parasolid to ignore the user fields which were saved with the part, create user fields of the length required by the current session, and set them to zero.
For further information see the "User fields" section in Chapter 58, "Session Support".
If a part has user-defined attributes attached, the attributes and their definitions are transmitted with the part. When the part is then received into a session, the kernel automatically loads the attribute definition of the attributes, if there is no definition with the same name already in the session.
If the attribute definition already exists in the new session, and matches the definition saved with the part, the part can be retrieved. However, if the two definitions have the same name but do not match, the process fails.
There is no problem retrieving system defined attributes attached to a part.
PK_PARTITION_transmit transmits a partition to a logical file through the Frustrum. As for part files, the transmit format may be text, machine-dependent binary, neutral binary or applio (output via application-registered functions).
If the option to also transmit deltas is selected, then:
When a partition is archived, the following items are saved:
and optionally, in a separate file:
PK_PARTITION_receive receives a partition from a logical file through the Frustrum:
If the application also wants to load the partition's pmarks and deltas, it must set the option PK_PARTITION_rcv_deltas_later_c, to enable it to call PK_PARTITION_receive_deltas.
PK_PARTITION_receive_deltas receives the pmark graph and deltas for a given a partition from a logical file through the Frustrum:
receive_prev_version_deltas
was given to PK_PARTITION_receive, in which case deltas transmitted from earlier compatible releases of Parasolid may be receivableDeltas can only be received for a partition if that partition was received earlier in the session, with option PK_PARTITION_rcv_deltas_later_c, and the pmark which the partition was at immediately after being received, has not been deleted. However, the partition may be modified, and pmarks created, between receiving the partition and receiving its deltas. This is illustrated in the following series of diagrams.
Figure 42-1 Pmark graph as transmitted
Figure 42-2 Pmark graph after partition is received
Figure 42-3 Pmark graph after some modeling has occurred
Figure 42-4 Pmark graph after deltas are received
| <<< Partitions and Rollback | Chapters | Assemblies and Instances >>> |