The concepts that are defined in this section relate to the FDO operations used to manage and manipulate data.
In FDO, the application uses a command to select and update features, define new types of feature classes, lock features, version features, and perform some analysis of features. Each Command object executes a specific type of command against the underlying data store. Interfaces define the semantics of each command, allowing them to be well-defined and strongly typed. Because FDO uses a standard set of commands, providers can extend existing commands and add new commands, specific to that provider. Feature commands execute against a particular connection and may execute within the scope of a transaction.
An FDO command is a particular FDO interface that is used by the application to invoke an operation against a data store. A command may retrieve data from a data store (for example, a Select command), may update data in a data store (for example, an Update or Delete command), may perform some analysis (for example, an Activate Spatial Context command), or may cause some other change in a data store or session (for example, a Begin Transaction command).
An expression is a construct that an application can use to build up a filter. An expression is a clause of a filter or larger expression. For example, “Lanes >=4 and PavementType = 'Asphalt'” takes two expressions and combines them to create a filter.
For more information about using expressions with FDO, see Filter and Expression Languages.
A filter is a construct that an application specifies to an FDO provider to identify a subset of objects of an FDO data store. For example, a filter may be used to identify all Road type features that have 2 lanes and that are within 200 metres of a particular location. Many FDO commands use filter parameters to specify the objects to which the command applies. For example, a Select command uses a filter to identify the objects that the application wants to retrieve. Similarly, a Delete command uses a filter to identify the objects that the application wants to delete from the data store.
For more information about using filters with FDO, see Filter and Expression Languages.
A user can use locking to gain update control of an object in the data store to the exclusion of other users. There are two general types of locks—transaction locks and persistent locks. Transaction locks are temporary and endure only for the duration of the transaction (see What Is a Transaction?).
Persistent locks applied to objects by a user remain with the object until either that user removes those locks or the locks are removed by another user with the appropriate authority.
A transaction changes the data store in some way. The way these changes affect the data store is determined by the transaction’s properties. For example, the Atomic property specifies that either all changes happen or non happen. In transaction processing the data store treats a series of commands as a single atomic unit of change to that data store. Either all changes generated by the commands are successful or the whole set is cancelled. A transaction is a single atomic unit of changes to a data store. The application terminates a transaction with either a “commit,” which applies the set of changes, or a “rollback,” which cancels the set of changes. Further, the data store may automatically roll back a transaction if it detects a severe error in any of the commands within the transaction. A transaction has the following properties:
- Atomic. Either all changes generated by the commands within a transaction happen or none happen.
- Consistent. The transaction leaves the data store in a consistent state regarding any constraints or other data integrity rules.
- Isolated. Changes being made within a transaction by one user are not visible to other users until after that transaction is committed.
- Durable. After a transaction is completed successfully, the changes are persistent in the data store on disk and cannot be lost if the program or processor fails.
A long transaction (LT) is an administration unit used to group conditional changes to objects. Depending on the situation, such a unit might contain conditional changes to one or to many objects. Long transactions are used to modify as-built data in the database without permanently changing the as-built data. Long transactions can be used to apply revisions or alternates to an object.