Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DOC Document reverting a change to table names #78

Merged
merged 1 commit into from
Sep 1, 2022
Merged

DOC Document reverting a change to table names #78

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 0 additions & 2 deletions en/04_Changelogs/5.0.0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,8 +25,6 @@ This is a major release and as a result there are a number of breaking API chang
their aliases (applied by setting a string key for the array) were being ignored. This bug has been fixed - if you were working around this by manually setting the alias e.g. in a join, you can remove those workarounds now.
- [Query](api:SilverStripe\ORM\Connect\Query) now implements `IteratorAggregate` instead of `Iterator`. This means `seek()` and other iterator methods are no longer available on this class and its subclasses. Use `getIterator()` instead.
- [DataList](SilverStripe\ORM\DataList), its subclasses, [Map](api:SilverStripe\ORM\Map), and [ArrayList](SilverStripe\ORM\ArrayList) all now return generators from `getIterator()`. This reduces memory usage when looping over large result sets. As a result of this, `getGenerator()` has been removed as it is no longer needed. Note that `chunkedFetch()` has not been removed, as it may still be useful for very large result sets to fetch results in smaller chunks at a time.
- For `DataObject` subclasses without a `table_name` defined, the default table name will now be shorter. This reduces the chance that the default table name will be too long for the database to handle - but best practice is still to explicitly declare `table_name` for all `DataObject` subclasses.
- If you have hardcoded references (e.g. in raw SQL queries) to table names for `DataObject` subclasses which are using a default table name, you may need to change those references. Best practice here is to use [DataObjectSchema](api:SilverStripe\ORM\DataObjectSchema) methods such as `baseDataTable()`, `tableName()`, and `tableForField()` to get the appropriate table names if you need to write raw SQL queries.

## Features and enhancements {#features-and-enhancements}

Expand Down