For this simple situation, they are indeed the same the [Condition 1] [Condition 2] and [Condition 1 and Condition 2] notation become different when using them in specific situations.
For example when filtering on two attributes from a relation:
[/relation/object[Attribute1 = x AND Attribute2 = x]]
Returns a different SQL query then
[relation/object/Attribute1 = x][relation/object/Attribute2 = x]
In the first example, Mendix knows to group the two statements to one join path. In the second example Mendix will setup two join paths in the from part of the SQL query. As you can see using the correct format can give you a better SQL query.
Perhaps someone from Mendix can get into the specifics, but I did a quick check with a microflow retrieve. In my situation the SQL generated by Mendix doesn't differ at all. Running
[Condition 1 AND Condition 2]
returned the same SQL query as when running
[Condition 1][Condition 2]
By the looks of it, Mendix is able to generate a 'general' SQL statement based on your XPATH restrictions with placeholders. The exact values you pass along are then added to the placeholders through the RequestAnalyzer.
(If you set the log level for ConnectionBus_Retrieve to Trace, you can monitor what's going on under the hood. )
It depends on condition 1 and condition 2.
Furthermore, the not expression is an expensive one and you should try to avoid it if you can.
Scenario #1 [/relation/object[Attribute1 = x AND Attribute2 = x]] Returns a different SQL query then Scenario #2 [relation/object/Attribute1 = x][relation/object/Attribute2 = x]
Scenario #1 will retrieve less than Scenario #2, because in scenario one the attributes need to be on the same object while in scenario #2 the original object needs to have at least one relation to an object with attribute1 =x and one relation to an object with attribute 2 = x
I've added a Mendix 5.21 project with data snapshot to demonstrate this effect and an image to illustrate Image