This is a migrated thread and some comments may be shown as answers.

FetchField.Next with circular references

5 Answers 73 Views
Databases and Data Types
This is a migrated thread and some comments may be shown as answers.
This question is locked. New answers and comments are not allowed.
BNS
Top achievements
Rank 1
BNS asked on 22 May 2012, 03:40 PM
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

5 Answers, 1 is accepted

Sort by
0
Jan Blessenohl
Telerik team
answered on 25 May 2012, 12:38 PM
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
Follow @OpenAccessORM Twitter channel to be the first one to get the latest updates on new releases, tips and tricks and sneak peeks at our product labs!
0
BNS
Top achievements
Rank 1
answered on 25 May 2012, 12:48 PM
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'.
0
Jan Blessenohl
Telerik team
answered on 25 May 2012, 01:40 PM
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
Follow @OpenAccessORM Twitter channel to be the first one to get the latest updates on new releases, tips and tricks and sneak peeks at our product labs!
0
BNS
Top achievements
Rank 1
answered on 25 May 2012, 01:52 PM
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
0
Thomas
Telerik team
answered on 04 Jun 2012, 05:30 PM
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
Follow @OpenAccessORM Twitter channel to be the first one to get the latest updates on new releases, tips and tricks and sneak peeks at our product labs!
Tags
Databases and Data Types
Asked by
BNS
Top achievements
Rank 1
Answers by
Jan Blessenohl
Telerik team
BNS
Top achievements
Rank 1
Thomas
Telerik team
Share this question
or