[Solved] FetchField.Next with circular references

[BNS]

I have the following Class:

[Telerik.OpenAccess.Persistent(IdentityField = "id")]
public partial class Address
{
    [Telerik.OpenAccess.FetchField("AddressShort")]
    private int id; // pk

    [Telerik.OpenAccess.FetchField("AddressShort")]
    private string city;

    [Telerik.OpenAccess.FetchField("AddressFull")]
    private string street;

    [Telerik.OpenAccess.FetchField("AddressFull")]
    private string zip;

    [Telerik.OpenAccess.FetchField("AddressFull", Next = "AddressShort")]
    private Address alternativeAddress;
}

This is some test code to fetch objects of this Class:

using (var scope = _database.GetObjectScope())
{
    scope.FetchPlan.Set(new[] { "AddressFull" });
    var addresses = scope.Extent<Address>().ToList();
    Assert.IsNotEmpty(addresses);
}

(Adding "AddressShort" to the Fetchplan, doesn't make any differrence.)
OpenAccess generated the following SQL-Statements:

SELECT a.[Id] COL1,
    a.[AlternativeAddress] COL2,
    a.[City] COL3,
    a.[Street] COL4,
    a.[Zip] COL5,
    b.[Id] COL6,
    b.[AlternativeAddress] COL7,
    b.[City] COL8,
    b.[Street] COL9,
    b.[Zip] COL10
FROM [Address] a
LEFT JOIN [Address] AS b ON (a.[AlternativeAddress] = b.[Id])

But I expected OpenAccess to use the AddressShort FetchPlan for references, so the SQL-Statement should look something more like this:

SELECT a.[Id] COL1,
    a.[AlternativeAddress] COL2,
    a.[City] COL3,
    a.[Street] COL4,
    a.[Zip] COL5,
    b.[Id] COL6,
    b.[City] COL7,
FROM [Address] a
LEFT JOIN [Address] AS b ON (a.[AlternativeAddress] = b.[Id])

This might not be a problem with this little Testclass, but our Businesslayer contains Classes / Tables with more than 200 Fields and 10 circular References.

Is there any error in my definition of the FetchPlans, or have I misunderstood the concept of Fetchplans? What is the best way to meet my requirements?

Thanks,
Bianco Veigel



[Jan Blessenohl]

Hi Bianco,
we are always including the default fetch group. If you do not want to load the extra strings each time, you should remove them from the DFG by using:
[DefaultFetchGroup(false)]

All the best,
Jan Blessenohl
the Telerik team

[BNS]

I thought that configuring the Fetchplan using "scope.FetchPlan.Set" removes all previous and also the Default Fetchplan. Anyway I've applied the attribute an tested again, but it doesn't seem to work as expected.

Here's my new Telerik Class:

[Telerik.OpenAccess.Persistent(IdentityField = "id")]
public partial class Address
{
    [Telerik.OpenAccess.FetchField("AddressShort")]
    private int id; // pk

    [Telerik.OpenAccess.FetchField("AddressShort")]
    private string city;

    [Telerik.OpenAccess.FetchField("AddressFull")]
    [Telerik.OpenAccess.DefaultFetchGroup(false)]
    private string street;

    [Telerik.OpenAccess.FetchField("AddressFull")]
    [Telerik.OpenAccess.DefaultFetchGroup(false)]
    private string zip;

    [Telerik.OpenAccess.FetchField("AddressFull", Next = "AddressShort")]
    [Telerik.OpenAccess.DefaultFetchGroup(false)]
    private Address alternativeAddress;
}

And this is the SQL-Statement I got:

SELECT a.[Id] COL1,
    a.[AlternativeAddress] COL2,
    a.[Street] COL3,
    a.[Zip] COL4,
    b.[Id] COL5,
    b.[AlternativeAddress] COL6,
    b.[City] COL7,
    b.[Street] COL8,
    b.[Zip] COL9
FROM [Address] a
LEFT JOIN [Address] AS b ON (a.[AlternativeAddress] = b.[Id])

I expected, that OpenAccess selects only id and city for the joined address 'b'.

[Jan Blessenohl]

Hi Bianco,
You are right, we do not remove a fetchgroup if we follow the next setting. This means your scenario works well if you do not have a self reference. I do not see a way to handle this at the moment. How many self references do you have?

Regards,
Jan Blessenohl
the Telerik team

[BNS]

After a short research I found at least 4 Tables/Objects which have at least 10 self references in total. Removing the self reference is not an option for us, so it would be a great performance improvement if the fetchgroup is removed when following the next setting.

Regards
Bianco Veigel

[Thomas]

Hi Bianco,

we will be working on this after the next release as we probably have not enough time to do this before.
We are sorry for the inconvenience this might cause.

Kind regards,
Thomas
the Telerik team