| |
Version Controls |
| <<< Session Support | Chapters | Implementing Version Control In Applications >>> |
As improvements are made to Parasolid, the behaviour of some functions may change in certain conditions. In the vast majority of cases your application should take advantage of these changes in behaviour. However, sometimes your application might need to rely on the old (inferior) behaviour. Typically, this may be the case if you need to ensure that legacy parts are updated consistently. Rarely, it may be because you are unable to make the necessary adjustments to your application immediately. In these cases you need to be able to reproduce the inferior behaviour in newer Parasolid versions. Parasolid supports two separate version control systems to allow you to manage this behaviour in your application code.
|
For legacy parts created in newer versions of Parasolid, you should use a consolidated version control mechanism that includes the ability to emulate the behaviour of any specific customer release in V28.1 or later. All customers integrating version control for the first time should use this system. |
||
|
For legacy parts created in older versions of Parasolid (including all versions prior to V28.1), Parasolid provides a system of session switches and update switches. Update switches can be used to emulate legacy behaviour for specific APIs, whereas session switches can be used to emulate legacy behaviour across a session. Session switches are described in Section 116.3, “Reproducing behaviour using the original system”. Chapter 118, “Update Switches”, lists all the update switches that are available in the Parasolid PK interface. |
The consolidated system provides a number of benefits over the original system:
This chapter describes both version control systems in detail:
Chapter 117, “Implementing Version Control In Applications”, provides implementation advice on how to use the two systems, depending on the needs of your application. This includes specific advice on how to implement version control using both systems.
This section describes the APIs you need to use to make use of the consolidated system. See Chapter 117, “Implementing Version Control In Applications”, for specific examples on how to implement version control using these APIs.
In order to manage version control in your application, you need to decide what session behaviour you need to specify. Parasolid lets you choose between three different types of session behaviour, as follows:
|
Use the latest behaviour for the current version of Parasolid. This is the behaviour that you should use most of the time (i.e. whenever you do not need to emulate older versions of Parasolid). |
|
|
Use the behaviour from a specific release of Parasolid. This type of behaviour can be used to emulate any release (full or patch) from the point at which you first implemented the consolidated system. Use the unset behaviour if you need to emulate older versions of Parasolid. |
|
|
Use this behaviour if you need to emulate Parasolid behaviour from versions released before you implemented the consolidated system. Using this type of behaviour enables the original system, allowing you to emulate old behaviour by setting session switches for the entire Parasolid session, and update switches for individual functions. Section 116.3, “Reproducing behaviour using the original system”, explains how to use session switches. Chapter 118, “Update Switches”, describes the update controls available for individual Parasolid functions. |
You use the functions PK_SESSION_set_behaviour and PK_SESSION_ask_behaviour to manage which version control behaviour is used in a Parasolid session.
PK_SESSION_set_behaviour sets a specific behaviour for the session. It receives a single argument,
behaviour_requested
, and returns three arguments,
behaviour_set,
behaviour_previous
, and a
status
:
behaviour_requested |
The version control behaviour that you wish to use in the current Parasolid session. |
behaviour_set |
The version control behaviour that was set as a result of the call to PK_SESSION_set_behaviour.
In some circumstances, this may not be the same as |
behaviour_previous |
The version control behaviour that was in use prior to the call to PK_SESSION_set_behaviour. |
status |
A return status for the operation, as follows:
|
|
Note: We recommend that you do not change the session behaviour by calling PK_SESSION_set_behaviour from within a callback function. |
PK_SESSION_ask_behaviour lets you find out which version control behaviour is currently in use in your Parasolid session. This function returns a single
behaviour
argument.
In addition, PK_SESSION_ask_latest_behaviour returns the latest allowed behaviour of the modeller, regardless of any behaviour that may have been set via a call to PK_SESSION_set_behaviour in the current Parasolid session.
Every argument for these functions uses a structure of type PK_SESSION_behaviour_t, which contains the following fields:
behaviour_type |
The type of behaviour for the session. This is one of:
See Section 116.2.1, “Session behaviours”, for more information. |
behaviour_value |
If
For example, 280103 specifies a specific patch release of V28.1, and 290000 specifies the FCS release of V29.0.
When used as a received argument in PK_SESSION_set_behaviour, if
When used as a returned argument in PK_SESSION_set_behaviour or PK_SESSION_ask_behaviour, if |
Warning: When creating a new feature, you should record the non-zero
behaviour_value
returned by PK_SESSION_ask_behaviour and store it with that feature. This value should then be used when rebuilding the feature in future versions. You should always store the
behaviour_value
returned by PK_SESSION_ask_behaviour rather than trying to programmatically predict or reconstruct this value yourself. See Chapter 117, “Implementing Version Control In Applications”, for more information. |
|
Note: Like other session-level controls, behaviour values do not roll with partitioned rollback. |
In order to emulate legacy behaviour for features created in applications that do not use the consolidated sytem, you need to use a combination of session switches and update switches:
In addition, after First Customer Shipment (FCS) of a Parasolid version, improvements to behaviour may be added to subsequent patch releases. You can use a session switch to turn on these improvements when creating new models.
Session-level switches are manipulated by the following two functions:
|
Set session-level switches to turn off specific improvements to functionality. |
|
There are three general types of session-level switches:
The values of session-level switches are stored in the PK_SESSION_software_option_t structure.
Session level switches that only affect a small number of customers are shown below, organised according to the Parasolid version whose behaviour they replicate. To turn a particular switch on, set the value for the corresponding field to 1.
|
Smooth intersection curve edge generation along blends (between the blend itself and the adjacent supporting surface). Note: Many Parasolid functions may need to recompute side blend boundary edges; setting this field does not solely affect blend creation. |
||
|
Calculation of minimum radius of curvature on each side of swept and spun surfaces |
||
|
Checks partitions during transmit and makes PK_PARTITION_transmit return an error if a corruption is found. You should only enable this option if specifically instructed to do so by Parasolid Support. |
||
|
Region behaviour in respect of tag persistence, and attribute and group handling |
||
|
Preventing the creation of large vertex tolerances in sheet extend operations |
||
Between Parasolid V25.0 and Parasolid V30.1, a session switch value with a name of the form PK_SESSION_pre_v XXX_switch_0_c (where XXX represents a Parasolid version number) is available for every version of Parasolid.
These session switch values are used as version switches that control the behaviour of multiple low-level algorithms, and you need to treat them differently to the session switch values described in Section 116.3.1.
When rebuilding all features where that feature has been built in a prior version of Parasolid, you should set the appropriate session switch values in order to guarantee a successful rebuild. All available switches should be set, up to and including the version switch for the version of Parasolid you are using to perform the rebuild.
For example, if you are rebuilding features created in Parasolid v25.1, and you are using Parasolid v26.1 to perform the rebuild, you must set PK_SESSION_pre_v260_switch_0_c and PK_SESSION_pre_v261_switch_0_c to 1.
|
Warning: These switches should
not be used unless explicitly advised to do so by Parasolid Support. |
As of Parasolid V26.1, session switch values with names of the form PK_SESSION_post_v XXX_switch_ n_c (where XXX represents a Parasolid version number, and n represents a switch number) may be available for versions of Parasolid.
These post session switches are added at patch releases after a major Parasolid release (FCS), and allow you to take advantage of improvements in Parasolid behaviour that have been made since FCS, without having to wait for the next major release. They should only be used for creating new models in the Parasolid version number for which they are named, and for subsequent update of those models.
If your application needs to deal with legacy data and you use post session switches, then you must record which models use which post session switches. After upgrading to a newer major version of Parasolid, you must set the same post session switches when you need to update these models, as were used when the model was created.
For example, consider the case where Parasolid V26.0 is integrated into your application code:
|
Warning: In general, for a given Parasolid version
X, it is an error to set both PK_SESSION_post_v
X_
n_c and PK_SESSION_pre_v
X_0_c, for all values of
n. |
You can use the functions PK_DEBUG_behaviours_start and PK_DEBUG_behaviours_stop to debug your use of the version control mechanism in your application. See the documentation for these functions in the PK Interface Programming Reference Manual for more information.
| <<< Session Support | Chapters | Implementing Version Control In Applications >>> |