Database abstraction broken up into controller, connector, query builder, and schema manager, each independently configurable via YAML / Injector
Creation of new DBQueryGenerator for database specific generation of SQL
Support for parameterised queries, move of code base to use these over escaped conditions
Refactor of SQLQuery into separate query classes for each of INSERT UPDATE DELETE and SELECT
Support for PDO
Installation process upgraded to use new ORM
SS_DatabaseException created to handle database errors, maintaining details of raw sql and parameter details for user code designed interested in that data.
Renamed DB static methods to conform correctly to naming conventions (e.g. DB::getConn -> DB::get_conn)
3.2 upgrade docs
Performance Optimisation and simplification of code to use more concise API
API Ability for database adapters to register extensions to ConfigureFromEnv.php
Remove all top/bottom margins from buttons and apply to GridFieldButtonRow component. Ensure that all buttons are added to a suitable GridFieldButtonRow in ModelAdmin, SecurityAdmin and Group.
Running Members() on a Group that has no Db record causes UnsavedRelationList to be returned by DirectMembers() which in turn causes alterDataQuery() to fall over when called on an UnsavedRelationList. This just adds a simple check to prevent it.
The call to Members() includes members of child groups, which was causing any members added through the grid field to be added to the child groups as well.
It would invalidate this view. Only allow group editing
for new members added to this group (with a group default),
and for members edited through the "root" view.
Due to changed return value of DataObject::get(),
the (negated) check always returned false.
This wasn't noticed in 3.0 because Group->canEdit() is rarely
enforced, but does become noticeable in 3.1 where GridField
checks those object-level permissions.
Thanks to @purplespider for reporting!
In 3.0 there was some confusion about whether DataLists and ArrayLists
were mutable or not. If DataLists were immutable, they'd return the result, and your code
would look like
$list = $list->filter(....);
If DataLists were mutable, they'd operate on themselves, returning nothing, and your code
would look like
$list->filter(....);
This makes all DataLists and ArrayList immutable for all _searching_ operations.
Operations on DataList that modify the underlying SQL data store remain mutating.
- These functions no longer mutate the existing object, and if you do not capture the value
returned by them will have no effect:
ArrayList#reverse
ArrayList#sort
ArrayList#filter
ArrayList#exclude
DataList#dataQuery (use DataList#alterDataQuery to modify dataQuery in a safe manner)
DataList#where
DataList#limit
DataList#sort
DataList#addFilter
DataList#applyFilterContext
DataList#innerJoin
DataList#leftJoin
DataList#find
DataList#byIDs
DataList#reverse
- DataList#setDataQueryParam has been added as syntactic sugar around the most common
cause of accessing the dataQuery directly - setting query parameters
- RelationList#setForeignID has been removed. Always use RelationList#forForeignID
when querying, and overload RelationList#foreignIDList when subclassing.
- Relatedly,the protected variable RelationList->foreignID has been removed, as the ID is
now stored on a query parameter. Use RelationList#getForeignID to read it.
Stay consistent with main member listing in admin/security,
and de-emphasize their importantce. Having the "link existing"
closer to the actual table is a much stronger UI coupling.
The entire framework repo (with the exception of system-generated files) has been amended to respect the 120c line-length limit. This is in preparation for the enforcement of this rule with PHP_CodeSniffer.
