Can anyone tell me how this parameter works in a prefetch path when its being done client side. I am looking at the query being run on the database and then looking at my actual resuls (entities) and don't see how the logic works?

When you define the prefetch path the collection that relates to that entity will have be filled in the same call as the entity fetch. If you have a max number of items defined then only that many entities will be placed in the related collection.

BTW cool site http://www.wrenchscience.com/

bclubb wrote:

When you define the prefetch path the collection that relates to that entity will have be filled in the same call as the entity fetch. If you have a max number of items defined then only that many entities will be placed in the related collection.

OK, lets say that I have two items returned that have the same id. What causes one item to be chosen over the other? I don't understand how the criteria for this works.

Thanks for the compliment on the site. Its this site that I'm rebuilding now using .net and LLBLGen Pro. This will be a huge improvement over the current site.

Which parameter are you referring to, if I may ask?

Otis wrote:

Which parameter are you referring to, if I may ask?

I'm using the following code the select data in a prefetch path, and then select the 1 from the top.

IPrefetchPathElement2 forkVersionNode = prefetchPath.Add( ForkEntity.PrefetchPathForkVersion, 1 );

Now let's say this query returns 4 rows. Two of the four have the same ProductID and other two also have the same ProductID. For each of the two rows one is chosen, how is this one chosen? Is it whichever one happens to be first or last?

tprohas wrote:

Otis wrote:

Which parameter are you referring to, if I may ask?

I'm using the following code the select data in a prefetch path, and then select the 1 from the top.

IPrefetchPathElement2 forkVersionNode = prefetchPath.Add( ForkEntity.PrefetchPathForkVersion, 1 );

Now let's say this query returns 4 rows. Two of the four have the same ProductID and other two also have the same ProductID. For each of the two rows one is chosen, how is this one chosen? Is it whichever one happens to be first or last?

If you fetch 10 customers, and you want their last 2 orders, this is done in 2 queries. First the customers are read, then the orders. The orders are filtered client side, for the reason taht you can't specify TOP per group.

For the root entities (customer) the PK values are used to calculate hash values. For the orders, for the FK field belonging to the relation customer - order, also hashvalues are calculated.

per root entity a counter is created. Now, the engine will start at the top of the orders and read the row. It picks the FK field(s) and calculate a hashvalue. It then tries to find a match in the customer pk hashes. If it finds one, it will assign the order to the customer and increase the counter. If the counter hits the limit set, the customer won't get any more order objects in the resultset. If all counters have reached the limit or the resultset is empty, it will stop. This is build on top of the entity collection fetch code, so it's not using a datareader which is used per row.

It also doesn't specify TOP (#rootentities * limit), as that might not be correct, due to joins in a filter and DISTINCT isn't applyable.

Otis wrote:

tprohas wrote:

Otis wrote:

Which parameter are you referring to, if I may ask?

I'm using the following code the select data in a prefetch path, and then select the 1 from the top.

IPrefetchPathElement2 forkVersionNode = prefetchPath.Add( ForkEntity.PrefetchPathForkVersion, 1 );

Now let's say this query returns 4 rows. Two of the four have the same ProductID and other two also have the same ProductID. For each of the two rows one is chosen, how is this one chosen? Is it whichever one happens to be first or last?

If you fetch 10 customers, and you want their last 2 orders, this is done in 2 queries. First the customers are read, then the orders. The orders are filtered client side, for the reason taht you can't specify TOP per group.

For the root entities (customer) the PK values are used to calculate hash values. For the orders, for the FK field belonging to the relation customer - order, also hashvalues are calculated.

per root entity a counter is created. Now, the engine will start at the top of the orders and read the row. It picks the FK field(s) and calculate a hashvalue. It then tries to find a match in the customer pk hashes. If it finds one, it will assign the order to the customer and increase the counter. If the counter hits the limit set, the customer won't get any more order objects in the resultset. If all counters have reached the limit or the resultset is empty, it will stop. This is build on top of the entity collection fetch code, so it's not using a datareader which is used per row.

It also doesn't specify TOP (#rootentities * limit), as that might not be correct, due to joins in a filter and DISTINCT isn't applyable.

Otis, thank you I believe that this answers my question.