tonyair/silverstripe-framework
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-framework synced 2024-09-30 05:09:06 +02:00
Code Issues Projects Releases Wiki Activity

[doc] Update to Silverstripe 4 convention

Browse Source 
- The Silverstripe 4 folder structure has been changed from **app/code/** to **app/src/**
- Renamed Silverstripe in text. I assume `api:` and `Namespace`, should remain SilverStripe
- Added some missing semicolons
This commit is contained in:
Pen y Fan 2021-05-31 19:08:03 +01:00 committed by GitHub
parent a3df66860f
commit bba872e02c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 67 additions and 67 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
docs/en/02_Developer_Guides/00_Model/01_Data_Model_and_ORM.md
View File

@ -6,21 +6,21 @@ icon: database
# Introduction to the Data Model and ORM
SilverStripe uses an [object-relational model](http://en.wikipedia.org/wiki/Object-relational_model) to represent its
Silverstripe uses an [object-relational model](http://en.wikipedia.org/wiki/Object-relational_model) to represent its
information.
* Each database table maps to a PHP class.
* Each database row maps to a PHP object.
* Each database column maps to a property on a PHP object.
All data tables in SilverStripe are defined as subclasses of [DataObject](api:SilverStripe\ORM\DataObject). The [DataObject](api:SilverStripe\ORM\DataObject) class represents a
All data tables in Silverstripe are defined as subclasses of [DataObject](api:SilverStripe\ORM\DataObject). The [DataObject](api:SilverStripe\ORM\DataObject) class represents a
single row in a database table, following the ["Active Record"](http://en.wikipedia.org/wiki/Active_record_pattern)
design pattern. Database Columns are defined as [Data Types](/developer_guides/model/data_types_and_casting) in the static `$db` variable
along with any [relationships](relations) defined as `$has_one`, `$has_many`, `$many_many` properties on the class.
Let's look at a simple example:
**app/code/Player.php**
**app/src/Player.php**
```php
use SilverStripe\ORM\DataObject;
@ -41,7 +41,7 @@ so on. After writing this class, we need to regenerate the database schema.
## Generating the Database Schema
After adding, modifying or removing `DataObject` subclasses, make sure to rebuild your SilverStripe database. The
After adding, modifying or removing `DataObject` subclasses, make sure to rebuild your Silverstripe database. The
database schema is generated automatically by visiting the URL http://www.yoursite.com/dev/build while authenticated as an administrator.
This script will analyze the existing schema, compare it to what's required by your data classes, and alter the schema
@ -49,18 +49,18 @@ as required.
It will perform the following changes:
* Create any missing tables
* Create any missing fields
* Create any missing indexes
* Alter the field type of any existing fields
* Rename any obsolete tables that it previously created to _obsolete_(tablename)
* Create any missing tables
* Create any missing fields
* Create any missing indexes
* Alter the field type of any existing fields
* Rename any obsolete tables that it previously created to _obsolete_(tablename)
It **won't** do any of the following
* Delete tables
* Delete fields
* Rename any tables that it doesn't recognize. This allows other applications to coexist in the same database, as long as
their table names don't match a SilverStripe data class.
* Delete tables
* Delete fields
* Rename any tables that it doesn't recognize. This allows other applications to coexist in the same database, as long as
their table names don't match a Silverstripe data class.
[notice]
@ -76,7 +76,7 @@ automatically set on the `DataObject`.
* Created: A date/time field set to the creation date of this record
* LastEdited: A date/time field set to the date this record was last edited through `write()`
**app/code/Player.php**
**app/src/Player.php**
```php
use SilverStripe\ORM\DataObject;
@ -129,7 +129,7 @@ Using the `create()` method provides chainability, which can add elegance and br
[/notice]
Database columns and properties can be set as class properties on the object. The SilverStripe ORM handles the saving
Database columns and properties can be set as class properties on the object. The Silverstripe ORM handles the saving
of the values through a custom `__set()` method.
```php
@ -299,7 +299,7 @@ You can also sort randomly. Using the `DB` class, you can get the random sort me
```php
$random = DB::get_conn()->random();
$players = Player::get()->sort($random)
$players = Player::get()->sort($random);
```
## Filtering Results
@ -595,15 +595,15 @@ equivalent version.
Methods which return class names:
* `tableClass($table)` Finds the class name for a given table. This also handles suffixed tables such as `Table_Live`.
* `baseDataClass($class)` Returns the base data class for the given class.
* `classForField($class, $field)` Finds the specific class that directly holds the given field
* `tableClass($table)` Finds the class name for a given table. This also handles suffixed tables such as `Table_Live`.
* `baseDataClass($class)` Returns the base data class for the given class.
* `classForField($class, $field)` Finds the specific class that directly holds the given field
Methods which return table names:
* `tableName($class)` Returns the table name for a given class or object.
* `baseDataTable($class)` Returns the base data class for the given class.
* `tableForField($class, $field)` Finds the specific class that directly holds the given field and returns the table.
* `tableName($class)` Returns the table name for a given class or object.
* `baseDataTable($class)` Returns the base data class for the given class.
* `tableForField($class, $field)` Finds the specific class that directly holds the given field and returns the table.
Note that in cases where the class name is required, an instance of the object may be substituted.
@ -642,16 +642,16 @@ you need it to, you may also consider extending the ORM with new data types or f
You can specify a WHERE clause fragment (that will be combined with other filters using AND) with the `where()` method:
```php
$members = Member::get()->where("\"FirstName\" = 'Sam'")
$members = Member::get()->where("\"FirstName\" = 'Sam'");
```
#### Joining Tables
You can specify a join with the `innerJoin` and `leftJoin` methods. Both of these methods have the same arguments:
* The name of the table to join to.
* The filter clause for the join.
* An optional alias.
* The name of the table to join to.
* The filter clause for the join.
* An optional alias.
```php
// Without an alias
@ -692,7 +692,7 @@ Note: Alternatively you can set defaults directly in the database-schema (rather
## Subclasses
Inheritance is supported in the data model: separate tables will be linked together, the data spread across these
tables. The mapping and saving logic is handled by SilverStripe, you don't need to worry about writing SQL most of the
tables. The mapping and saving logic is handled by Silverstripe, you don't need to worry about writing SQL most of the
time.
For example, suppose we have the following set of classes:
@ -740,18 +740,18 @@ foreach($news as $article) {
The way the ORM stores the data is this:
* "Base classes" are direct sub-classes of [DataObject](api:SilverStripe\ORM\DataObject). They are always given a table, whether or not they have
special fields. This is called the "base table". In our case, `SiteTree` is the base table.
special fields. This is called the "base table". In our case, `SiteTree` is the base table.
* The base table's ClassName field is set to class of the given record. It's an enumeration of all possible
sub-classes of the base class (including the base class itself).
sub-classes of the base class (including the base class itself).
* Each sub-class of the base object will also be given its own table, *as long as it has custom fields*. In the
example above, NewsSection didn't have its own data, so an extra table would be redundant.
example above, NewsSection didn't have its own data, so an extra table would be redundant.
* In all the tables, ID is the primary key. A matching ID number is used for all parts of a particular record:
record #2 in Page refers to the same object as record #2 in [SiteTree](api:SilverStripe\CMS\Model\SiteTree).
record #2 in Page refers to the same object as record #2 in [SiteTree](api:SilverStripe\CMS\Model\SiteTree).
To retrieve a news article, SilverStripe joins the [SiteTree](api:SilverStripe\CMS\Model\SiteTree), [Page](api:SilverStripe\CMS\Model\SiteTree\Page) and NewsPage tables by their ID fields.
To retrieve a news article, Silverstripe joins the [SiteTree](api:SilverStripe\CMS\Model\SiteTree), [Page](api:SilverStripe\CMS\Model\SiteTree\Page) and NewsPage tables by their ID fields.
## Related Lessons
* [Introduction to the ORM](https://www.silverstripe.org/learn/lessons/v4/introduction-to-the-orm-1)