About changesets
A changeset can be described as an own copy of the map where you can create, change and delete objects or components without affecting the database. It is not possible to open the application without a changeset because all work in the application is done in changesets. This applies even if you do not want or have permission to create or edit data, but only want to search, find or view data in the application.
All the changes that you perform in the application, for example when you create new objects, move components or update an attribute form for an object, are not immediately saved in the database*. Instead, all changes are first performed and stored in the changeset. The changeset is a table containing all the data changes you have made in the application in one or more work session. You can work with many different changesets and store your ongoing changes in one or more separate changeset. The changes that are stored in a changeset are temporary. To update the original data in the database you need to post your changeset. Each changeset has a unique ID number to distinguish them. Changesets can be exchanged between users in the system as different steps in a workflow.
These are some of the most important characteristics of a changeset:
•All the work in dpPower are performed in one or more changesets.
•To start dpPower you must first select a changeset.
•Changesets have unique names and ID's.
•A user may own and use more than one changeset.
•Users may exchange changesets, as part of a work-flow process.
•When you post a changeset its content are saved in the database.
* One exception concerns auto posting object types, which are implemented in modules such as Operator. One advantage of using this method is that it makes it possible to allow users without posting rights access to many application operations, while the system automatically executes any necessary postings to the database.
The dialog Select changeset
Once you have logged in to the application, the dialog Select changeset is opened. The same dialog opens when you select File > Open... (Ctrl-O) from the menu bar in the application.
The dialog Select changeset, presents a list of the changesets that you currently own, along with information about its name, comment, and date it was created. In the dialog you may:
•Open a changeset owned by your username.
•Create a new changeset.
•Edit the name or comment of an existing changeset.
•Delete a changeset.
Pessimistic and optimistic changeset
When you create a new changeset, you must specify whether your changeset should be pessimistic or optimistic.
|
•Pessimistic change sets are suitable to use when large amounts of new documentation are to be performed, where the user is responsible for their own delimited areas. •Optimistic change sets are suitable to use when you want to develop and explore several different expansion proposals that all contain common network components. |
Pessimistic changesets
If you work with a pessimistic changeset, you effectively prevent other users to edit and post the same objects that you are editing in your changeset. In other words, any objects that you have deleted or edited in your pessimistic changeset and yet not posted to the database are locked in the database. Similarly, you will not be able to edit application data that is being edited in another users pessimistic changesets. Users working with optimistic changesets may edit locked objects, but are unable to post these changes.
Any object in the map view that is locked in this manner, can be visualized by selecting to show locked objects in a user-defined color. Furthermore, you can access information about the user and changeset that is currently locking an object, that is preventing you to edit it. This enables you to contact that user and ask them to make the object accessible again. The user who owns the changeset that locks the object can either unlock the changeset or post the changese to remove the locking of objects.
Optimistic changesets
Working with an optimistic changeset means that objects are not locked to other users in the system. Working with optimistic changesets allow users to edit the same application data simultaneously. This has some obvious advantages since access to application data is uninterrupted. Problems can arise if the same attribute in a component is edited in parallel in different changesets. In such a case, conflict management must be performed when posting to determine which of the edit versions that is valid and should be saved to the database.
Postable and Unpostable changeset
It is only when a changeset is posted that its contents are saved to the database.
•Postable - All changes in the changeset can be posted. Posting means that the changes that have been made in the changeset are saved in the database and thus become visible to other users. This is the default setting.
•Unpostable - The changeset cannot be posted. The changes made are only in the changeset and are not available to other users. This means that system postings are not carried out either.
•System post - Only the system is allowed to post changes to the changeset. An example of when system posting is carried out is in connection with operating orders in the Operator module. When the user performs a report on an outage, the system automatically posts this change to the database.
•Private - No one else can review the changeset. It does not appear in the list of changesets. In the changeset graphical view, private is indicated by a sunglasses symbol. A changeset associated with a task cannot be Private. When the changeset is sent to another user, the changeset remains private, but to the new user.
|
•Use postable changeset when all changes made in your changeset should be able to be posted to the database and thereby update or change the original data. •Use unpostable changeset when changes made to your changeset should not be able to be posted to the database and thus not update or change the original data. This means that system postings are not carried out either. •Use system postings when only the system is allowed to post changes to your changeset. |
Additional options
In the application there are many more ways to work with changesets. In the File menu you will find alternatives that allows you to:
•Post... - Posts/sends any changes you have made in the application to the database, updating original data.
•Empty changeset... - Allows you to undo all the changes you have made in a changeset, effectively emptying it of content without saving it to the database.
•Open... - Allows you to select another changeset or create a new one.
•Review... - Allows you to open and view a changeset belonging to another user of the system.
•Send... - Allows you to transfer your changeset to any user of the system.
•Convert - Converts the current type of changeset - from optimistic to pessimistic, or the other way around.
•Create copy... - Creates a copy of an existing optimistic changeset.
•Synchronize and handle conflicts - Produces a list of any conflicts contained in a changeset.
More information
See also: