I realy like using LIKE as a condition and this allow me to use % as a default value if the parameter is empty but it’s missing from condition list in db query…
I can do it in with a custom query and works fine. (i love the test query feature there anyway)
eg:
SELECT * FROM Tasks WHERE Tasks.t_status LIKE :P1 AND Tasks.fk_member_id = :P2
:P1 = {{$_GET.t_status.default("%")}}
Just curious why it’s missing for db query.
thanks
/J
I expect a lot of people like using LIKE - and it would surprising if it were not available. It’s here:
begins with = like string%
ends with = like %string
contains = like %string%
doesn’t = ! does
thanks, I suspected that but then i thought contains means to contain. I want either a direct match or everything. Using %string% is not a direct match. In my case it will work fine anyway but i feel it’s not right. If it works, it works. 
Yupp just tested it. I have field with string ‘On Hold’
using Contains ‘On’ i get 1 record.
using custom query with LIKE ‘On’ i get 0 records - this is correct
anyway in my scenario it won’t matter i can search for ‘on hold’ and get result i want. but to me Contains is not Like…
That’s exactly what Contain is supposed to do.
If you want to match the string exactly why not use Equal ?
Becuase if the Get parameter is empty i can use .default("%") and list all records…
maybe it’s old fashioned that’s how i used to it back in the day… I’ve been away from programming for a while.
Cool didn’t think of that… Tested it and it works i had no idea what that first field did
Can you clarify that, not sure what you mean.
How would you form the query you mean in SQL?
Well with LIKE you get a direct match like = but also have option for wildcard. see first post
Contains is different than LIKE.
But with a condition like Teodor said we get same effect.
This is one of my favourite features of Query Builder. It makes it possible to create quite elaborate queries - eg including a combination of conditional groups and individual rules. You can use conditions for sorting similarly (which is something you can’t do with custom queries - at least I don’t think you can).
Yupp i just realized how useful that can be, i needed that few days ago!
In the conditions @TomD , can you do something more complex in those.
ie. the normal condition to add something such as {{$_GET.id}} which checks if parameter is complete then the Where clause is applied, have you tested things like {{$_GET.idA}}&&{{$_GET.idB == 4}}&&{{$_GET.idC !== 5}}
Im sure my syntax is incorrect, i’m just checking though, because i haven’t really got this working as above style example, and i know you use those in a fairly elaborate way.
Hi @psweb. I expect you can add any valid expression in these conditions. I don’t think I’ve used anything a as complex as your example, but here’s an example of the type of expression I’ve used quite a lot:
{{$_GET.searchfield == “anyfield” && search.split(" ")[0]}}
Brilliant, thanks Tom, I was probably just getting mine wrong but if I know it is possible i will continue persevering with it. 
It’s probably just a matter of using one set of {{}} round the the whole expression.
Hello dear Wappler superstars !
I’m trying to get advantage of the query condition filter as explained above in this thread but I’m not sure how it works exactly…
Here is my query :
What I want is to filter by test_mode and order_current_status in every case.
But also filter by user_id only if the user_id is not empty.
I don’t know what I’m doing wrong as all I can get is an “all or nothing” filter applied.
Meaning… If user_id is passed, I get my query executed as expected.
If not, all my where clause is ignored and I get all rows in table returned.
Thank you very much for your help !
EDIT : I found my answer when trying something counter-intuitive…
Seems like if you use conditions, you have to use them on every branch of the where clause if you don’t want the “all or nothing” behavior described above.
In my case, I added a “dummy” condition that would be always true.
Which may be enough. However, I think you may be making things more complicated than necessary. I’ve never used a dummy condition like that. I think the problem may be the way the conditions are grouped/nested. I think it might be useful to look at this thread.
Awesome @TomD !
Thanks for the link.
I didn’t realise that one group was nested into the other.
So I tried with two different groups like you suggested :
In the examples you linked to, every group had a condition set.
From what I could test so far…
If no condition are set at all, then all empty condition will evaluate to true.
The problem seems to be that if you have at least one condition set…
In that case, other groups containing “where clause” with an empty condition will evaluate to false.
I don’t know if this is the expected behavior.
