Selector array with OR selectors

[elabx]

I have this selector:

$operacionesSelector = [];                                       
$operacionesSelector['template'] = ['transaccion', 'pago'];
                                                                             
$operacionesSelector[] = [
'pago_entity' => $user
];
$operacionesSelector[] = [
'transaccion_representante_cliente' => $user
];

$operacionesSelector['sort'] = "-created";
$operacionesSelector['status<'] = Page::statusTrash;

If I dump the PageArray object with tracy debugger I get this selector within it's properties: 

template=transaccion|pago, or1=(pago_entity=8828,title!=""), or2=(transaccion_representante_cliente=8828), sort=-created, status<8192

The problem is, I'm not getting the same results as this selector/find:

$pages->find("template=transaccion|pago,(pago_entity=$user), (transaccion_representante_cliente=$user), sort=-created, status<" . Page::statusTrash);

That translates within the tracy dump as:

template=transaccion|pago, =(pago_entity=8828), =(transaccion_representante_cliente=8828), sort=-created, status<8192

And this "normal" selector does return the expected pages. 

I don't see why my first selector does not find the pages it should, if I understand correctly the OR selectors, both of this selectors work the same and should find the same pages. Maybe I'm missing something about access control?? Though the template meant to be found shouldn't suppose any issue with the user roles/permissions.

[Zeka]

@elabx

$pages->find("template=transaccion|pago,(pago_entity=$user), (transaccion_representante_cliente=$user), sort=-created, status<" . Page::statusTrash);

In this selector you are using OR-groups. 

There is not much documantation, but you can look at this topics

https://github.com/processwire/processwire-issues/issues/264

[elabx]

Thanks for your help @Zeka! Did find this topic while searching for a hint. I am familiar with OR groups, but what I am trying to do here is "migrate" from using string selectors to array selectors, but I can't just get them to behave like its string equivalent! I understand it will be hard to debug this without the whole scope of the ProcessWire project but maybe some has been through the some of the same issues.

[Zeka]

@elabx Have you tried something like this?

$selector = [
    [
        'field' => 'template',
        'value' => ['transaccion', 'pago'],
        'operator' => '=',
    ],
    [
        'field' => 'pago_entit',
        'value' => $user,
        'operator' => '=',
        'or' => 'test',
    ],
        [
        'field' => 'transaccion_representante_cliente',
        'value' => $user,
        'operator' => '=',
        'or' => 'test'
    ],
    [
        'field' => 'sort',
        'value' => '-created',
    ],
    [
        'field' => 'status',
        'operator' => '<',
        'value' => Page::statusTrash,
    ]

];

Not sure that is it even the right direction as it produces such selector dump:

template=transaccion|pago, test@title=(41), test@email=(41), sort=-created, status<8192

 

[Robin S]

6 hours ago, elabx said:

what I am trying to do here is "migrate" from using string selectors to array selectors

Just my opinion: I'm not sure there's much advantage to doing that - selector arrays seem more trouble than they are worth. When you start needing things like OR groups and nested selectors (which you inevitably do) the array syntax gets quite verbose and frankly less readable than the string syntax (especially if you are already familiar with the string syntax). I can't locate the topic now but I remember @adrian working with selector arrays for a while and I think he ended up reverting back to selector strings because there were too many issues/hassles with the array syntax. Maybe he will correct me on that.

[adrian]

Yeah, @Robin S is mostly correct. The array approach seems like a good idea, but it will end up biting you in many cases. For ease of readability and building up complex selectors, I do build them with a regular php array and then simply implode the array with a comma to get the string selector. This is now my goto approach for any complex dynamic selectors.

[adrian]

PS, here's the thread @Robin S was referring to: 

 

[Robin S]

12 minutes ago, adrian said:

I do build them with a regular php array and then simply implode the array with a comma to get the string selector. This is now my goto approach for any complex dynamic selectors.

Not meaning to hijack this thread, but just curious what advantage you see to using an array that you later implode versus the more typical approach of using .= to concatenate to a selector string. Are you doing things like using an associative array that so that you can conditionally modify parts of the selector by key before you implode, or something like that? Or you just like to be able to more clearly see the different parts of the selector in a Tracy dump? 

[adrian]

2 minutes ago, Robin S said:

Are you doing things like using an associative array that so that you can conditionally modify parts of the selector by key before you implode, or something like that? Or you just like to be able to more clearly see the different parts of the selector in a Tracy dump? 

Actually all of the above, but yes, the Tracy dump is a key part of it - so much easier to see which parts are being added to the selector this way. I do also sometimes modify parts by key, but I also just find my code looks cleaner that concatenating a string with commas at the end of each one, plus you don't have to worry about a possible trailing comma.

[elabx]

@adrian thanks for your input! I guess I'll just give up (for now) ?

Hadn't thought of a particular advantage rather than I just like to avoid string concatenation just for a personal preference.  Pretty much like @adrian says, it looks cleaner imho.