Note that the platform uses different icons for regular and predefined catalog items (see fig. 3.73).
Despite the fact that users can edit the code or description for both items, they cannot edit the predefined item names that you specify in Designer. Later you will use these names to call the predefined items from 1C:Enterprise script.
So, the configuration algorithms can be based on predefined items.
Now you can see the main difference between regular and predefined catalog items from the configuration point of view.
Regular items are not permanent. Users can create and delete them. Although the configuration can distinguish them from each other, you cannot use them in the algorithms because they can disappear at any time.
Predefined items are permanent. They are always available, regardless of user actions.
In theory, users can delete predefined items but we will not give them rights for interactive deletion of predefined objects (or interactive deletion of any objects at all, see Lesson 22. Users and their roles).
Therefore, the configuration algorithms can rely on predefined items. This is why each predefined item has a unique name, so that it can be referenced using 1C:Enterprise script.
Base configuration and database configuration
Up to this point we have not dug deeply into the structure of the 1C:Enterprise system, but this is a good point for a few words on the subject.
You remember that, from the user perspective, a 1C application consists of the platform and the applied solution (configuration). We have already mentioned that each applied solution is a single configuration. But at this point we have to say this is not exactly true.
Why not true? Because each infobase has a minimum of two configurations.
Why not exactly true? Because in practice a user always works with a single configuration. The other configuration is intended for developers or for those who modify the configuration (for example, infobase administrators). It is not visible to users.
The configuration intended for developers is referred to as base configuration (or simply configuration). This is the one that you edit in Designer.
The configuration intended for user work is referred to as database configuration.
A base configuration can be edited, while a database configuration cannot be edited. Instead, a database configuration can be updated based on the base configuration.
But you may naturally ask the question: if I have two configurations, one that can be edited and another one where users work, why the editable one is referred to as the base configuration? From the end-user perspective, the base configuration is the one they work with.
But the base name is given from the developer perspective and makes great practical sense.
In general, a 1C:Enterprise infobase can store more than two configurations: the base configuration, the database configuration, and multiple vendor configurations.
Besides, a repository can exist outside of an infobase. It stores a configuration that is intended for shared development.
A certain number of configuration files can exist outside of the infobase as well, including files belonging to a new distribution package (fig. 3.74).
Fig. 3.74. Configuration structure
A vendor configuration within an infobase stores the previous delivery states. There are also scenarios where a configuration is supported by multiple vendors, each of them supporting their part as a standalone configuration. In this case the infobase contains multiple vendor configurations (the previous delivery state for each vendor).
New delivery files can exist in the form of configuration files (full distribution) or update files (update distribution).
A configuration repository contains a configuration intended for shared development. This configuration is stored as a set of individual objects assigned to specific configuration versions, rather than as a complete configuration. This allows developers to get a configuration version from the repository by assembling it from the individual objects.
Now imagine that there is a way to perform comparisons and updates between all these configuration types. In this case, it is easy for things to get into a muddle, so the name base configuration is the best way to reflect the overall goal of these changes.
Now that we are back to the base configuration and database configuration, note that internal division into two configurations gives developers the option to make modifications without any user work interruptions. This is possible because all the modifications are introduced into the base configuration that is not available to users.
Then, when the developer is confident that all the modifications are correct, they can use the base configuration to quickly update the database configuration.
If such modifications do not affect the database structure (for example, database tables do not need to be modified, only module script is changed), a database configuration can be updated without interrupting user work. This process is referred to as dynamic update.
Users will only see the changes after they restart their application. The DataBaseConfigurationChangedDynamically() method of 1C:Enterprise script is intended for checking whether the applied solution restart is required.
But if such modifications affect database structure (for example, a catalog has a new attribute or an existing attribute has a new type), all the user sessions must be terminated. The developer can compare the base configuration and the database configuration at any time, and they can roll back to the original version of the base configuration by reading the database configuration (if, for example, the introduced changes are a total mess).
So, the relationship between the two configurations can be depicted as follows (fig. 3.75).
Fig. 3.75. Relationship between base and database configurations
When a developer is working in the base configuration, the platform provides them with an indication whether the current version of the base configuration is different from the saved version, and whether the saved version of the base configuration is different from the database version.
If the developer is editing the base configuration and the edited version of the base configuration differs from the one that is saved, an asterisk (*) is displayed in the title of the configuration tree window, indicating that the configuration has been modified (fig. 3.76).
Fig. 3.76. Configuration tree window title
If the saved version of the base configuration is different from the database configuration, an exclamation mark (<!><!>) is displayed in the title of the configuration tree window (fig. 3.77).
Fig. 3.77. Configuration tree window title
To save the base configuration, on the Configuration menu, click Save configuration.
To update a database configuration, on the Configuration menu, click Update database configuration.
Once you click Start debugging on the Debug menu, the platform saves the base configuration and then compares it with the database configuration. If the configurations are different, you are prompted to update the database configuration as you saw in the preceding examples. Once you click Continue Debugging on the Debug menu, after the actions described above, the platform also prompts you to restart the applied solution in order to terminate the current debug session.
This is how the platform simplifies configuration development and automates frequently used actions.
When the database configuration is updated, the platform creates (or modifies) the database data structures that are defined as configuration objects.
When users add regular catalog items, they add them to the database structure based on the Catalog configuration object.
The platform adds predefined catalog items to that database structure according to their descriptions in the Catalog configuration object.
Again, this proves the fact that regular catalog items are not important from the configuration point of view, while predefined items are important because they might be used in the configuration algorithms.