XPath AND notation

0
If I retrieve an object from the database, I can use two notations to specify my XPath constraints: 1: [Condition 1 AND Condition 2] 2: [Condition 1] [Condition 2] From a functional perspective, these are the same. Is there a difference from a SQL/database perspective?
asked
4 answers
5

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.

answered
0

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. )

answered
0

It depends on condition 1 and condition 2.

  • If they belong to the entity that you are retrieveing from the database, then I would expect no difference.
  • As mentioned by Mitchel, it is a whole different story if you hop over associations to entities. From performance perspective, it is good to group these.

Furthermore, the not expression is an expensive one and you should try to avoid it if you can.

answered
-1

Hi all,

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

Mendix project

answered