unclecheese 119739de68 If a DataObject has a many_many to a SiteTree subclass, and that subclass has no database fields defined, and $this->name is "ID", this function will errantly return "SiteTreeSubClass.ID", which can never exist in a search query, since there is no such table as SiteTreeSubClass. The problem is that DataObject::hasOwnTableDatabaseField() is a little eager when passed an argument of "ID." It doesn't check to see if the object has its own table first.		2012-06-04 12:27:58 -03:00
..
filters	If a DataObject has a many_many to a SiteTree subclass, and that subclass has no database fields defined, and $this->name is "ID", this function will errantly return "SiteTreeSubClass.ID", which can never exist in a search query, since there is no such table as SiteTreeSubClass. The problem is that DataObject::hasOwnTableDatabaseField() is a little eager when passed an argument of "ID." It doesn't check to see if the object has its own table first.	2012-06-04 12:27:58 -03:00
FulltextSearchable.php	BUGFIX Versioned's constructor doesn't provide suitable defaults. Previously a bug/feature in singleton, where it would pass null,true as params to strong_create, which would then get passed through as params to Versioned's constructor, meant that the code still executed fine (as was set to something that wasn't an array, so the null and true were instead taken as args). The fact that the usage of singleton(Versioned) never really used the classes code, purely for value lookup, meant that this never propagated errors. I've now switched singleton() to use the injector for retrieving values, which means these dud values are no longer passed through	2012-05-23 21:10:04 +10:00
SearchContext.php	MINOR Update @package values to match renaming sapphire	2012-04-15 10:50:19 +12:00