anchor.diff:  |====
   
   
  +=== Automatic datasource binding
  +
   For traditional databases, automatic binding is initiated whenever a datasource is configured as follows:
   
   [source,properties]
  
positive.code: ----
  
  
  ==== Customizing automatic bindings
  
  Even though automatic binding was developed to eliminate as much manual configuration as possible, there are cases where modifying the generated `ServiceBinding` resource might  still be needed. The generation process exclusively relies on information extracted from the application and the knowledge of the supported Operators, which may not reflect what is deployed in the cluster. The generated resource is based purely on the knowledge of the supported bindable Operators for popular service kinds and a set of conventions that were developed to prevent possible mismatches, such as:
  
  * The target resource name does not match the datasource name
  * A non-default operator needs to be used
  * Version conflicts
  
  .Convetions
  
  * The target resource coordinates are determined based on the type of Operator and the kind of service.
  * The target resource name is set by default to match the service kind, such as `postgresql`, `mysql`, `mongo`.
  * For named datasources, the name of the datasource will be used.
  * For named `mongo` clients, the name of the client will be used.
  
  
  ====
  .Example 1 - Name mismatch
  
negative.code: 
  The `service key` is usually the name of the service, for example the name of the datasource, or the name of the `mongo` client. When this value is not available, the datasource type, such as `postgresql`, `mysql`, `mongo`, is used instead.
  
  To avoid naming conflicts between different types of services, prefix the `service key` with a specific datasource type, such as `postgresql-__<person>__`.
  
  The following example shows how to customize the `apiVersion` property of the `PostgresCluster` resource:
  
  [source,properties]
  ----
  