The 1C:Enterprise model for the development of applied solutions uses an object-based approach to data manipulation for some entities of a subject area. These entities are described in the configuration with the help of the following metadata objects: Catalog, Document, ChartOfCharacteristicTypes, ChartOfAccounts, and ChartOfCalculationTypes. From the point of view of the 1C:Enterprise data model, a database stores objects for these entities. Of course, the query language provides access to these entities, as well as to any other data, through the model of relational tables. However, access with specialized script objects intended for manipulating such data is provided through an object-based methodology.
Let us review the types used to manipulate these entities in the configuration. We will review the types and their use with the example of a catalog. A structure of similar types is used for the other metadata objects mentioned.
The CatalogsManager type is intended for accessing the managers of specific catalogs. In addition, it provides the AllRefsType() method to obtain the TypeDescription value that contains the reference types of all catalogs in the configuration. For instance, you can use this value (through a ContainsType() method) to check whether the type of a certain value is a reference type of some catalog.
The CatalogManager type provides access to common actions for a specific catalog. Its methods are used to perform activities related to a catalog, not to its specific objects. For instance, its methods can be used to create a new object or to find an object by code. The manager is a certain entry point to a specific catalog within an object model of the 1C:Enterprise script.
Note that the system can contain a single object of the CatalogsManager type and a single object of the CatalogManager type.
Let us now review the types CatalogRef and CatalogObject in more detail. The following figure shows how a catalog is stored in a database.
The catalog is stored in a table. Table entries define a database object, i.e., a catalog item. The database object includes an entry in the main catalog table and the entries from all the tabular sections of the catalog that relate to this object. Therefore, the database object is an entry that consists of the main table and tabular section rows.
A Ref field is included in a catalog table to store values that explicitly define objects (catalog items) in the 1C:Enterprise database. If you need to reference a database object in any other table, the field of this table will store the value of the Ref field.
Two major types are used to manipulate the catalog in the script: CatalogRef.???? and CatalogObject.????, where ???? is the metadata name of the catalog. It is important to note that there are distinct types for each catalog that are created in the system when a catalog is created in the metadata. Therefore, the reference types of two different catalogs will be different.
The purposes of types CatalogRef and CatalogObject are notably different. A value of type CatalogRef stores a reference that identifies an object in a database, while a value of type CatalogObject is used to read and write object data.
A value of type CatalogRef is used everywhere a reference to an item should be stored. Actually, the CatalogRef value only stores the internal identifier (the same that is stored in the Ref field of a catalog table). This value is stored in the fields of other database tables, it is selected in the input box and specified in the query parameters when data is searched via reference, and so on. It is important that a value of the type CatalogRef can always be compared with other values of the type CatalogRef and the values are always equal if these are the references to the same database object (regardless of the method used to obtain the value and its source).
A value of type CatalogObject is mostly used to create new objects or to modify or delete the existing ones. Besides, the CatalogObject type is used to display and edit all catalog item data in the form of an item. CatalogObject is also used to edit the rows of the catalog list (CatalogObject is not used to display list rows). You can obtain several objects of type CatalogObject for a single catalog item. These values are only equal if we are talking about the same script object. Two script objects obtained for one catalog item will not be equal, even if they read the same database object, and all object data is the same.
You can use a catalog manager to create an object. In this case, a new object that is not yet included in a database is created. If you write it, a new object appears in the database. You can obtain an object from a reference. In this case, the existing object referenced through a reference is read from the database. You can obtain an object from a selection (CatalogSelection) as well. Object data is then filled with the data read from the selection.
CatalogObject optimizes the process of writing changes into a database. For instance, if you have not changed the attributes of the object itself, only minimum information on changes will be written. If you have not changed any rows of a tabular section, the tabular section will not be written. If you only changed or added a few rows, only the ones that were modified or added will be written. However, if you have deleted rows or changed the order of the rows, all the rows of a tabular section will be written.
Optimistic locking is applied to the objects, i.e. the object cannot be written if it was changed in a database after reading. This feature ensures the logical integrity of modified objects. Anyone who modifies an object can be certain that their changes will not rewrite changes introduced by other users (in other sessions), or by other objects of the same session. This locking type does not prevent other sessions or the same session from changing the object. However, the object will not be written if it was changed in the database after reading and before writing.
In addition, there is a pessimistic locking mechanism that prohibits changes within this or other sessions before this script object removes the locking. Use the Lock() method to activate this mechanism. In general, it is used to block objects that are being edited in the form. Extension of a catalog item form automatically activates the locking to make sure that the user will be able to write the object once they start editing it.
Both CatalogReference and CatalogObject provide access to the object data (table field values) via properties. Since the purpose and usage of these types differ significantly, these scenarios are implemented differently as well. The CatalogObject value stores properties directly in the script object. When the existing object is being read, its properties are filled with database values, and new object properties are initialized with default values. The CatalogRef value reads data from a database when the properties are accessed. However, to eliminate the need to read data every time properties are accessed, object data is cached. If you access properties of a given database object via references, data is only read when you access the properties for the first time and after the system uncaches the object. Object data is stored in cache for about 20 minutes, but if at least 20 seconds passed and then the object is accessed, the system checks whether the database object was modified and updates the cached data if needed. If the object is written within this session, it is immediately updated in cache. The number of objects that can be stored in cache is limited. Note that the system uses separate caches for each transaction, so when you access object data via references you certainly get up-to-date data.
The CatalogSelection type is used for dynamic iteration through catalog items. The mechanism of object table selection does not differ much from the selections of other tables. Note that the items read in the selection can be obtained as CatalogObject values. In this case, they will not be read from the database again. The selection always reads object data in full (all fields and all tabular sections).
The CatalogList type is used to create a dynamic view of catalog data in the Table box control. You can set up the structure of the fields (columns) that are read, as well as set up filtering and sorting. The list reads data in portions as the user navigates through a table box.
The catalog also defines several extensions of controls and forms that can be used to interactively input and view catalog data. Extensions are not data types. They basically add some specific properties, methods, and events to the corresponding objects. In addition, extensions define any unusual behavior of forms and controls when a user configures the system and interacts with it.
Next page: Using script tools for working with applied objects