$searchable_fields defaulting to $summay_fields: error when method names are used

Showing 1-4 of 4 messages
$searchable_fields defaulting to $summay_fields: error when method names are used Martimiz 9/1/12 5:43 AM
Hi all,

It's perfectly allright to use method names in $summary_fields, but it leads to an error message when $searchable_fields are not defined:

[User Error] Uncaught Exception: Unable to traverse to related object field [SomeMethodName] on [MyObject]

Yet nowhere it states that you have to define $searchable_fields. What happens is $searchable_fields defaults to $summary fields, and $searchable_fields doesn't accept method names. And the error isn't very clear, people tend to blame the method name in $summary_fields, which is perfectly legit. What would be the proper course of action:

- strip out all method names in $searchable_fields, and suppress the error only if we have defaulted to $summary_fields?
- disable filtering alltogether if no searchable_fields are set (seems sort of logical to me)?
- leave it as it is?

(Existing) ticket here: http://open.silverstripe.org/ticket/6761

$searchable_fields defaulting to $summay_fields: error when method names are used Uncle Cheese 9/1/12 8:06 AM
Really glad we're bringing this up. I was surprised to see this bug get dragged into 3.0.

Unless maybe it's not a bug and this is the intended effect? I can't imagine how.

Re: $searchable_fields defaulting to $summay_fields: error when method names are used swaiba 9/1/12 9:03 AM
I think I had this when I upgraded to PHP 5.3 simon_w explained it was to do with the different behaviour of is_a which is confused if SomeMethodName is  an object, e.g. a dataobject as long as it isn't you are ok
Re: $searchable_fields defaulting to $summay_fields: error when method names are used Martimiz 9/2/12 5:17 AM

I've tested this on a function returning all kinds of stuff, allways getting the same error. It just seems to be wanting an existing Database field - or a DataList(?) - only.

DataObject.php line 2480

    public function relObject($fieldPath) {
        if(strpos($fieldPath, '.') !== false) {
            $parts = explode('.', $fieldPath);
            $fieldName = array_pop($parts);

            // Traverse dot syntax
            $component = $this;
            foreach($parts as $relation) {
                if($component instanceof SS_List) {
                    if(method_exists($component,$relation)) $component = $component->$relation();
                    else $component = $component->relation($relation);
                } else {
                    $component = $component->$relation();

            $object = $component->dbObject($fieldName);

        } else {
            $object = $this->dbObject($fieldPath);

        if (!($object instanceof DBField) && !($object instanceof DataList)) {
            // Todo: come up with a broader range of exception objects to describe differnet kinds of errors programatically
            throw new Exception("Unable to traverse to related object field [$fieldPath] on [$this->class]");
        return $object;

Also: you can point summary_fields dotnotated to a related class, say MyImage.Name and that works fine. searchable_fields, however, want to search the actual table MyImage, which is never created if the MyImage class has no $db fields of its own:

Couldn't run query: SELECT DISTINCT count(DISTINCT "MyObject"."ID") AS "0" FROM "MyObject" LEFT JOIN "MyImage" ON "MyImage"."ID" = "MyObject"."SomeImageID" INNER JOIN "File" ON "MyImage"."ID" = "File"."ID" WHERE ("File"."Name" LIKE '%blah%') Table 'xxxxx.MyImage' doesn't exist

I'd say that's a bug as well, though another one.

Last point: if someone were to actually set $searchable_fields = array(); wouldn't he then expect there to be no filters, logically thinking?

Op zaterdag 1 september 2012 18:03:20 UTC+2 schreef swaiba het volgende: