Models can define default order conditions that will cause issues with
postgres. By setting order=>false on all the queries emitted by
TreeBehavior, we can avoid this issue and not have issues with models
that define a default ordering.
Refs #5155
When using subqueries or joining against tables containing FROM the
results were bizzare and unexpected. By tokenizing the entire query we
can more accurately grab the fields.
Refs #3972
While it *did* work for single fields, isUnique could not be used to
validate the uniqueness across multiple fields as documented. Because
validation methods pass arguments in an order the validator did not
expect the validation method would not work correctly.
Fixes#4571
This reverts commit 5863adda42, reversing
changes made to 4c37cf6d4b.
There was no real issue. The lack of session cookie in CLI makes writing
tests a bit tricky which caused the confusion. Refs #4405, #4451.
Before 1fe943d6f1,
afterFind() is called twice with belongsTo/hasOne associations.
Although $results also doesn't contain associated records on first time,
it contains them on second time.
After 1fe943d6f1,
it doesn't work if associated records are used in afterFind.
This commit fixes it.
When reflecting timestamp columns in MySQL current_timestamp comes back
as the default value. This causes insertion errors later on as
'current_timestamp' is an invalid value for timestamp columns.
Refs #4184
Abstracts the `require_once` of the schema file so it can be done twice. The added second call is a fallback for the previous APP_DIR-based naming to provide backwards compatibility.
Removes now-obsolete CakeSchema tests that involved `Configure::read('App.dir')`. The CakeSchema::name is now always static (and predictable) in the default case.
Instead of using the `APP_DIR` constant, which may change between developer installations of a project and cause issues loading Schemas generated elsewhere, use a fixed string, 'App'.
This is related to CakeDC/migrations#184 and should fully resolve#4174.
When conditions are empty we can assume one of two things:
* The person made a mistake.
* The person is doing the join conditions in the where clause.
In both cases we should attempt to generate proper SQL.
Fixes#4189
