What type of relation is this scenario?

That makes sense, It means that the fruit table changed to node even if it is aliased after the SELECT statement. I was thinking about never changed, but it does makes sense that’s why there is an error because it should be

SELECT node.parent, node.lft, node.rgt

It means that the SQL statement first look for the FROM clause before looking at what is inside the SELECT statement.

Now I am curious to know what the order the Cursor takes when reading an sql statement. Now I know it looks for the FROM clause before the SELECT clause Where does the sequence follow after SELECT?

great information I will test after I change the SELECT statement aliases.

the ‘node’ alias table only ever looks at 1 entry - the one you’re targeting (In our example, the “Banana” node). The parent/chain alias table looks at the different parts of the chain that make up the path from the top of the tree to our target node.

As far as the ‘cursor’ in reading an SQL statement, i believe the appropriate response is “It depends.”

It will always start at the first word, but where it goes from there varies. (‘does x table in the select clause exist? we need to look at our FROM clause for that, then go back to the select clause to check the next thing, etc etc.’, or ‘Theres a function here, so i need to go evaluate that first - but that function contains a function, so i need to go evaluate THAT first, then put it into the other function…’) so the answer is rather convuluted there.

I agree with you to change to something else instead of fruits, we are going to convert this into a fruit market. Lol

I have tested most of the sql statements and they return wonderful results but most of them seem to run from root to leaf, or from node to leaf, no the other way around going up. For instance taking the example of Electronics, what about if I search for Plasma which is under televisions. Well once I get plasma i would like to know what its parent category only, which is televisions. but in most of the examples and sql statements in mysql page you sent me a couple of post above they all refer relationships from parent to children, or node to leafs no leafs to nodes or root or children to parent. How can I know which category is Plasma ? and being able to display it, will the cursor or parser will have to read backwards ? plasma, televisions, Electronics instead of the normal current way Electronics, Televisions, plasma.

Going Node-To-Root, the items are in order.

SELECT parent.name,parent.lft,parent.rgt
FROM food AS node,
food AS parent
WHERE node.lft BETWEEN parent.lft AND parent.rgt
AND node.name = “Banana”
ORDER BY parent.rgt;


Name,lft,rgt
Banana,8,9 <-- This is what we looked for.
Yellow,7,10  <-- This is Banana's parent.
Fruit,2,11 <-- This is Yellow's parent.
Food,1,18 <-- This is Fruit's parent. It doesnt have a parent (because we've run out of results), so it must be the root.

I cant really give you the result for your electronics example because i dont know the structure of the tree. But it would be an equivilant set of data.

Ok, The only different was the ORDER BY parent.rgt, then instead of iterating the child of bananas it iterated its parents, very interesting.

I have a question in the FROM clause how just by aliasing the food table AS node,
and food again AS parent, does the statement knows the first is referring to childrens and the other for the parents. Because I have changed the names food AS colo and parent AS refre, and it still has the same results as it it were named node and parent. how does the sql when to refer for parent and when to refer as node.

node and parent are not keywords; they have no meaning to mySQL. They are names that were chosen so that someone reading the query could understand what i meant. I could have said “FROM food AS tiger, food AS purple” and gotten the same results.

The relationship is established by telling the database what we’re interested in.

If I wanted the children of Banana,
I would want all the nodes WHERE child.lft BETWEEN banana.lft AND banana.rgt.
If I wanted the parents of Banana,
I would want all the nodes WHERE banana.lft BETWEEN parent.lft AND parent.rgt

Ok the relationship by telling SQL what we are interested in ok, I thought it was done at the FROM clause but I can see the relationship start taking form in the WHERE and BETWEEN clause in this case.

If I wanted the children of Banana,
I would want all the nodes WHERE child.lft BETWEEN banana.lft AND banana.rgt.

To make an example one relationship you mention in the previous post, WHERE child.lft. In this case we have Banana, a child of Yellow unfurtunally Banana doesn’t have child but instead of banana we can use Yellow which in deed has Banana as a child. So if supposing that we have this

If I wanted the children of Yellow,
I would want all the nodes WHERE child.lft BETWEEN Yellow.lft AND Yellow.rgt.

What do you mean by Child.lft? you mean number 8 of banana child? and Yellow lft 7 and yellow.rgt 10. What is in between 7 and 10 in this case the statement will display banana, 8 and 9 are in between 7 and 10? am I right?

For banana parent would be whatever is next to 8 and 9 which are the left and right of Banana.

I would want all the nodes WHERE banana.lft BETWEEN parent.lft AND parent.rgt

You’re correct. Yellow has a LFT of 7, and a RGT of 10.

What nodes have a LFT between 7 and 10? 2 of them. Yellow and Banana. (BETWEEN is inclusive)

In the examples i’m using, there’s always one “Fixed” pointer (the ‘Yellow’, in this example), and one “General” pointer (The child/parent/whatever). We define the fixed pointer in the second half of the WHERE. (WHERE … AND Yellow.name = ‘Yellow’) so that mySQL has some definate values (Yellow.lft and Yellow.rgt). The ‘General’ pointer then looks at all the nodes in the table, and finds those that match the other half of the WHERE (child.lft BETWEEN Yellow.lft AND Yellow.rgt)

WHERE (child.lft BETWEEN Yellow.lft AND Yellow.rgt)

in other words The SQL give the meaning to child.lft after it picks up all the nodes between Yellow.lft AND Yellow.right. I understand that’s the function right there whatever is inside the fixed pointers Yellow.lft AND Yellow.rgt then contain it within the child.lft general pointer or called child.lft? hope i am right.

Yes I just realized it will include even the sub-parent node here called Yellow which contain Banana inside itself. And as you Said BETWEEN is inclusive I realized that it will include it in there, which in the case I only want its child or Yellow child to display. Well in the statement above which only display local nodes meaning only banana.

SELECT node.name, (COUNT(parent.name) - (sub_tree.depth + 1)) AS depth FROM categories AS node, categories AS parent, categories AS sub_parent,
    (
    SELECT node.name, (COUNT(parent.name) - 1) AS depth
    FROM categories AS node,
    categories AS parent
    WHERE node.left_node BETWEEN parent.left_node AND parent.right_node
    AND node.name = :node_name
    GROUP BY node.name
    ORDER BY node.left_node
    )AS sub_tree
WHERE node.left_node BETWEEN parent.left_node AND parent.right_node
    AND node.left_node BETWEEN sub_parent.left_node AND sub_parent.right_node
    AND sub_parent.name = sub_tree.name
GROUP BY node.name
HAVING depth = 1
ORDER BY node.left_node

In the directions it say to take < symbol out if I want the root node out, in this case Yellow 0 is out and it only display Banana but with an annoying 1 next to it, I was wondering how can I take out the Level number 1. Lol.

with the symbol of < at the HAVING clause display like with the parent Yellow with a death of 0

[QUOTE]
name – Yellow
depth – 0
name – Banana
depth – 1

[/QOUTE]

without the symbol of < at the HAVING clause display without the parent Yellow with a death of 0

[QUOTE]
name – Banana
depth – 1
[/QOUTE]

wondering how to take out that depth number.

It seems like the SELECT within first SELECT is selecting a node within another node. am I correct, WEll that very interesting, it means it can go infinite.

If it possible to go through three SELECT containing eachother to obtain a node a third depth level and after digging to a third level only display the third level? as in the query above where it goes one level down with the options of displaying depth 0 YELLOW and depth 1 BANANA and also displaying only Banana the 1 depth level and omitting the depth 0?

Just want to make if the same theory with of digging into one depth can apply to digging into a two or three depth query.

dont request the depth number? Why do you want the depth number anyway?

If you dont want the node, add another AND to your WHERE.
AND child.name != ‘Yellow’ (or AND child.lft != Yellow.lft works fine too)

or for that matter “WHERE child.lft BETWEEN (Yellow.lft + 1) AND Yellow.rgt” works fine too.

Still the number is in there I don’t know what is putting that number in there
check the COUNT function with no avail.

Those number don’t want to miss the show.

(COUNT(parent.name) - (sub_tree.depth + 1)) AS depth

is what puts the number in the results… but if you’re not going to check the depth, you dont need 90% of the query you just posted.

EDIT: What structure is the table you’re trying to use this query on? It looks like it’s an Adjacency Model instead of a Nested Set.

I think you are right I have an Adjacency model which for the next step wasn’t quite going to work.

is this Structure an Adjacency model? that’s the one I am using

CREATE TABLE IF NOT EXISTS categories (
category_id int(11) NOT NULL AUTO_INCREMENT,
name varchar(20) NOT NULL,
left_node int(11) NOT NULL,
right_node int(11) NOT NULL,
PRIMARY KEY (category_id)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=12 ;

Not my bad I am using a nested set model

okay you’re using ‘left_node’ and ‘right_node’ as indexes. Alright. So… what exactly are you trying to do?

You are right if I take the

(COUNT(parent.name) - (sub_tree.depth + 1)) AS depth
and the
HAVING depth = 1
then number disappear, but a vital function will disappear as well which is accessing the nodes by depth. For instance.

with the function

(COUNT(parent.name) - (sub_tree.depth + 1)) AS depth
and the HAVING clause, the query is able to only access nodes by level, for instance it can access RED and YELLOW nodes only without the parent FRUIT and if
sub_tree.depth + 2
instead of
sub_tree.depth + 1
then it will only access the next level of NODES after RED and YELLOW which are CHERRY and BANANA only without displaying FRUIT node and RED and YELLOW node levels in this case only CHERRY and BANANA. and I imagine that if you keep adding + 3 it will keep displaying the subsequent nodes.

Is there would be a way to get rid of that number and leaving that precious function or taking out the functions and approaching desire results with a different query structure to be display desired level alone in relation to the parent called.

even thought we were referring as Node.lft in the forum I always changed it to the indexes in the table structure here at the local server database. so that was not an issue. I always changed to the local structure.

I’m still… trying to understand what it is you want your query to do.