Negative lookup for ID in selector not working?

[Adam Kiss]

Hi all (or possibly only Ryan ),

assuming 5 children in the /parent/, reserved is checkbox, which was just added, so is unchecked everywhere

I have following query :

<?php
 $query = $pages->find('parent=/parent/, id=5780|5800, reserved=0');
 echo count($query);

It correctly selects 2 pages and echoes 2. But this:

<?php
 $query = $pages->find('parent=/parent/, id!=5780|5800, reserved=0');
 echo count($query);

doesn't return 3, it returns 5. Isn't this implemented, is it bug or do I fuck something up?

edit: correction: I previously stated it returns no children, but realized it returns all children. I also added other thing into query, because it's in an original query, to be closer to the real one

edit 2: upon more inspection, follwoing too doesn't work:

<?php
  $query = $pages->find('parent=/parent/, !id=5780|5800, reserved=0');
  echo count($query);

But this seems to work:

<?php
  $query = $pages->find('parent=/parent/, reserved=0')->not('id=5780|5800');
  echo count($query);

[ryan]

PW is treating that literally exactly what it says:

id != 5780 OR id != 5800

If you read that logic, you'll see that it can't ever exclude pages from that. But it's a bit of a mind game, because I think people actually see this, even though it's not what it says:

id != 5780 AND id != 5800

Anyway, the proper way to state such a condition in a selector is:

id!=5780, id!=5800

But what is the point of a OR "|" in a negative condition? Considering your example, it seems the "|" in a negative condition is useless. I'm thinking we should have the PageFinder engine consider the "|" (OR) an AND when in a multiple value negative selector ... because this seems like a more natural/expected behavior. I had assumed it must be a bug when first trying it, because I was looking for the same behavior you were until I realized PW was actually doing what it was supposed to... though this behavior seems futile. I'm going to change it unless anyone else wants to weigh in on this or catches some logic I might be missing?

[apeisa]

Reminds me of classic sql injection: 1=1 OR...

It seems like a good idea to think negative or as an and.

[ryan]

Thanks -- This logic has been updated in the latest commit.

[Adam Kiss]

The thing is, that if it's stated as this:

id != 5467|4567|9870

It should be rewritten as this:

id != (5467 OR 4567 OR 9870)

which in turn translates to

id != 5467 AND id != 4567 AND id != 9870

I think this is correct way in mathematical logic, although I have no proof at hand right now, so I might be mistaken

so the problem isn't in PW per se, rather then in translation from complex query to chain of simple queries.

But, regardless whether it is correct logic or not, common sense tells you how it should act, which in turn you already implemented in new commit. Thanks.

Edit:

I actually found evidence:

id != 5467 | 6574

understood the same as

!(id = 5467 || id = 6574)

which, rewritten is

id != 5467 && id != 6574

evidence !(x = 5467 || x = 6574) on wolfram|alpha

So, actually, there is mathematical bug in negative queries – OR should be understood as AND

[apeisa]

Actually those parenthesis are very important: !x = 5467||6574 on wa. I'm not sure about this (it's been while since I was in school...), but my two cents are here:

id != 5467|4567|9870

could be rewritten as:

id != 5467 OR id != 4567 OR id != 9870

but not:

id != (5467 OR 4567 OR 9870)

[Adam Kiss]

I think the only problem here is translating selector's code into mathematics. I would use language as a bridge

id != 10|20|30

The only (I hope) possible explanation is, that you want pages, which id isn't 10 or 20 or 30. Meaning you don't want pages, which id is 10 or 20 or 30. Correct? I think yes:) This sentence is much easier to transfer to mathematical logic, because you can clearly change it to 'Pages NOT with id = 10 or 20 or 30'.

!(id = 10 || id = 20 || id = 30) => id!=10 && id!= 20 && id!=30

Note: The sequence in [ code ] brackets is the only correct mathematic translation of !(x||y). The problem is transferring the linguistic construction into correct mathematical equation.

[apeisa]

Yes, if we think for what developer intents when he/she wrotes id!=10|20|30 we do have clearly right solution here. And because other way around doesn't make any sense (using OR in selectors with negative condition) this is safe change and great one too (makes the selectors cleaner).

[ryan]

I don't think as much about the mathematical stuff (as much as the SQL stuff), so I'm glad you guys are looking at it in this perspective too. Ultimately we're translating to SQL logic and the 'making sense' part is preferable to mathematical rules since selectors are a form of data queries rather than mathematical statements. But ProcessWire selectors are something new and aren't based on any existing standard, so we're kind of defining the standard here, and that's what I really like about these discussions. The more thinking that goes into the details like this the stronger it will be.