These base classes provide standard CRUD (create, retrieve, update and delete)
methods, etc. <!--fixme why the etc? what else?? -->
The generated DAO object has:
* A property for each field using the actual field name, not the unique name
* A `links()` method which retrieves the links to other tables (off the foreign keys)
* An `import()` method and an `export()` method for ?
* A `fields()` method which returns an array of fields for that object keyed by the field's unique name. Looking at the field 'pledge.amount' we see
* A couple of functions to define the labels for enumerated fields
```php
'pledge_amount'=>array(
'name'=>'amount',
'type'=>CRM_Utils_Type::T_MONEY,
'title'=>ts('Total Pledged'),
'required'=>true,
'import'=>true,
'where'=>'civicrm_pledge.amount',
'headerPattern'=>'',
'dataPattern'=>'',
'export'=>true,
'bao'=>'CRM_Pledge_BAO_Pledge',
'table_name'=>'civicrm_pledge',
'entity'=>'Pledge',
),
```
The key is the unique name but the name field is the field's name and the 'where' field shows the MySQL description of it. We also see the data type and whether it is available for search or export.
The DAO has a property for each field (using the actual field name, not the
unique name). They also have standard CRUD (create retrieve update delete) type
functions, etc. <!--fixme why the etc? what else?? -->
Generally fields should be exportable unless there is a security reason or they are weird and confusing as the search builder is also driven by this setting.
Fields whose option values can be calculated will also have a `pseudoconstant` section.
### BAO
BAO stands for business access object. BAOs map to DAOs and extend them with
Looking in [`/xml/schema/Pledge`](https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Pledge)
as an example we see 4 files:
-`files.xml`
-`Pledge.xml`
-`PledgePayment.xml`
-`PledgeBlock.xml`
The `files.xml` is just a list of the other files. Each of the other files describes a
table in the database, defining both table-leve and field-level metadata
including foreign keys and indexes:
The files.xml is just a list of the other files. Each of the others represents a
table in the Database. The XML files describe the database and are used to
build both the DAO files and the new database SQL generation script.
```
<table>
<base>CRM/SMS</base>
<class>History</class>
<name>civicrm_sms_history</name>
<comment>SMS History can be linked to any object in the application.</comment>
<add>1.4</add>
<drop>2.0</drop>
... etc
```
The XML describes fields, foreign keys and indexes, an example of a field definition is:
An example of a field definition is:
```
<field>
...
...
@@ -165,3 +237,13 @@ The XML describes fields, foreign keys and indexes, an example of a field defini
<add>2.1</add>
</field>
```
<!-- fixme:
The field 'amount' in the table 'pledge' has a unique name to distinquish it from fields in other tables (e.g. contribute) with the same field. This isn't consistent in all tables and I am trying to find out the reason / rules for this. Also, I presume 'import' means the field is exposed for .... imports?.-->
We can see that the above 'pledge_amount' field was added in CiviCRM v2.1.
Occassionally tables are dropped from the core schema so will not have associated DAOs.
