Prefetch Path Problem (?)

Posts   
 
    
psandler
User
Posts: 540
Joined: 22-Feb-2005
# Posted on: 27-Jul-2006 20:26:50   

(ORM Support Classes version 1.0.20051.060425)

This is actually not a problem, as we determined that what we were trying to do was not done purposely (so really a bug in our code). Still, the result was unexpected.

I can email DDL/code if required, but since it might be a known behavior, I thought I would post the general question here first.

Basically we were doing a prefetch path that involved a 1:1 relationship between X and Y. X was actually a subpath of another entity BASE with which it also has a 1:1 relationship.

The fetch went BASE (the base entity of the prefetch) => subpath X1 => subpath Y => subpath X2

(1 and 2 added for clarity)

So you would expect that you could access BASE.X1.Y.X2.

The odd thing was, both Y and X2 came back as null, even though the data was there to support them. In addition, when I ran this fetch with the profiler running, all queries returned the correct data.

Is this expected behavior?

bclubb
User
Posts: 934
Joined: 12-Feb-2004
# Posted on: 28-Jul-2006 03:02:16   

Can you post the code to create the prefetch and possibly the tracce of the queries that are run to fetch the entities.

psandler
User
Posts: 540
Joined: 22-Feb-2005
# Posted on: 28-Jul-2006 18:01:12   

bclubb wrote:

Can you post the code to create the prefetch and possibly the tracce of the queries that are run to fetch the entities.

Unfortunately I can't post anything publicly. I'm going to have to try to reproduce it with Northwind or another test database.

It wouldn't do any good to send the LGP file and prefetch code without the DDL, would it? I not only can't post the DDL, I can't even send it via email. cry

I will try to reproduce it this weekend and post it.

psandler
User
Posts: 540
Joined: 22-Feb-2005
# Posted on: 28-Jul-2006 18:42:26   

One more bit of info.

The aforementioned X1 and X2 actually consist of a view, so the prefetch paths are the result of custom relations.

Not sure if that sheds any more light on the subject. I will still try to reproduce this weekend.

psandler
User
Posts: 540
Joined: 22-Feb-2005
# Posted on: 28-Jul-2006 23:10:15   

I know it's nerdy to keep adding to my own thread, but . . .

This came up again, same situation. Once again I pointed out that it didn't make any sense to fetch a 1:1 back into another 1:1.

As I was fixing the code, I realized that the end of the 2nd 1:1 fetch should already be filled in anyway, since it's a circular reference, and LLBL handles those references.

So . . . I'm still going to try to reproduce (I sound like a broken record), since it's an oddity. But it's really a non-issue.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39927
Joined: 17-Aug-2003
# Posted on: 29-Jul-2006 10:41:14   

If you could produce a repro case (small) and mail it to us it would be great! simple_smile

Frans Bouma | Lead developer LLBLGen Pro
psandler
User
Posts: 540
Joined: 22-Feb-2005
# Posted on: 29-Jul-2006 23:42:00   

Otis wrote:

If you could produce a repro case (small) and mail it to us it would be great! simple_smile

I was able to reproduce with a test case and the latest build (version 1). Will bundle up and mail right after I post this.

For the record, some of the info I posted was incorrect. BOTH Base and X are views, and the relation between Base and X is 1:M, not 1:1. So there is more than one custom relation involved.

Anyway, I'll send the DDL, LGP, and my project directory in a minute.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39927
Joined: 17-Aug-2003
# Posted on: 30-Jul-2006 10:45:35   

Thanks! simple_smile I've received the email, and will look into it. simple_smile

Frans Bouma | Lead developer LLBLGen Pro