Typed Lists - pulling hair out

Posts   
 
    
bmoeskau
User
Posts: 54
Joined: 15-Jun-2005
# Posted on: 22-Sep-2005 12:23:00   

This seemed like it should have been pretty simple. It has been aggravating to say the least. I defined a typed list in the LLBL designer with the following relations:


Member.MemberID - TaskMember.MemberID (1:n)
Task.TaskID - TaskMember.TaskID (1:n)
Task.TaskTypeID - TaskType.TaskTypeID (m:1)

This is a pretty standard set of relations: two entity tables (Member and Task) and a foreign key relation table (TaskMember). TaskType is a lookup table for task descriptions. I am trying to get back a typed list by MemberID (i.e., give me all tasks for member with MemberID = X). The typed list contains a bunch of fields mixed from all three tables.

Everything I try results in this most helpful error message:

Relation at index 1 doesn't contain an entity already added to the FROM clause. Bad alias?

I have searched high and low and the only reference I have found in the forum was in relation to building a dynamic list, not a typed list. Since I am not aliasing anything or adding any relations directly, I don't see how that would be an issue. Obviously I'm not specifying some relations that I should be or not writing the filter correctly. I have no idea confused

Here's the code:


public static MemberTasksTypedList GetTasksListForMember(int memberId) 
{
    MemberTasksTypedList tasks = new MemberTasksTypedList();

    IRelationPredicateBucket filter = (IRelationPredicateBucket)tasks.GetRelationInfo();

    filter.PredicateExpression.Add(PredicateFactory.CompareValue(
        TaskMemberFieldIndex.MemberID, ComparisonOperator.Equal, memberId));

    using (DataAccessAdapter daa = new DataAccessAdapter())
    {
        daa.FetchTypedList(tasks.GetFieldsInfo(), tasks, filter, 0, null, true);
    }
    return tasks;
}

I also tried comparing to MemberFieldIndex.MemberID with the same result. Do I have to specify more than just the MemberID to make it work??? I'm not sure why that would be since I thought all of the necessary relations were already there via the .GetRelationInfo() call. I have seen reference to the order of the relations being important, but it was not clear to me why this is or how I can even tell what the order is. I pretty much followed the example from the help file almost exactly (minus the sort clause).

I had this working using an entity collection, but since it is read-only data that will be bound to a DataGrid, the typed list performance seemed desirable. Surely I'm missing something simple???

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 22-Sep-2005 12:44:37   

Could you please check what the generated relations are and paste them here in the routine BuildRelationSet() ?

Also, which designer version are you using? (please state the date in the about box).

Frans Bouma | Lead developer LLBLGen Pro
bmoeskau
User
Posts: 54
Joined: 15-Jun-2005
# Posted on: 22-Sep-2005 12:49:56   

Otis wrote:

Could you please check what the generated relations are and paste them here in the routine BuildRelationSet() ?

Also, which designer version are you using? (please state the date in the about box).

Not sure if the ResultSet matters, so I'm throwing it in as well:


private void BuildRelationSet()
{
    _filterBucket.Relations.ObeyWeakRelations = base.ObeyWeakRelations;

    _filterBucket.Relations.Add(MemberEntity.Relations.TaskMemberEntityUsingMemberID, "", "", JoinHint.None);
    _filterBucket.Relations.Add(TaskEntity.Relations.TaskTypeEntityUsingTaskTypeID, "", "", JoinHint.None);
    _filterBucket.Relations.Add(TaskEntity.Relations.TaskMemberEntityUsingTaskID, "", "", JoinHint.None);
}

private void BuildResultset()
{
    _fields = new ResultsetFields(AmountOfFields);

    _fields.DefineField(TaskMemberFieldIndex.MemberID, 0, "MemberID", "", AggregateFunction.None);
    _fields.DefineField(TaskFieldIndex.TaskID, 1, "TaskID", "", AggregateFunction.None);
    _fields.DefineField(TaskFieldIndex.ParentTaskID, 2, "ParentTaskID", "", AggregateFunction.None);
    _fields.DefineField(TaskFieldIndex.Title, 3, "Title", "", AggregateFunction.None);
    _fields.DefineField(TaskFieldIndex.IsReminder, 4, "IsReminder", "", AggregateFunction.None);
    _fields.DefineField(TaskFieldIndex.IsRecurring, 5, "IsRecurring", "", AggregateFunction.None);
    _fields.DefineField(TaskFieldIndex.Location, 6, "Location", "", AggregateFunction.None);
    _fields.DefineField(TaskFieldIndex.Priority, 7, "Priority", "", AggregateFunction.None);
    _fields.DefineField(TaskFieldIndex.Notes, 8, "Notes", "", AggregateFunction.None);
    _fields.DefineField(TaskFieldIndex.Duration, 9, "Duration", "", AggregateFunction.None);
    _fields.DefineField(TaskFieldIndex.Visibility, 10, "Visibility", "", AggregateFunction.None);
    _fields.DefineField(TaskFieldIndex.ShowTimeAs, 11, "ShowTimeAs", "", AggregateFunction.None);
    _fields.DefineField(TaskFieldIndex.Url, 12, "Url", "", AggregateFunction.None);
    _fields.DefineField(TaskFieldIndex.PercentComplete, 13, "PercentComplete", "", AggregateFunction.None);
    _fields.DefineField(TaskFieldIndex.DueDate, 14, "DueDate", "", AggregateFunction.None);
    _fields.DefineField(TaskTypeFieldIndex.Description, 15, "TaskType", "", AggregateFunction.None);
    _fields.DefineField(MemberFieldIndex.DisplayName, 16, "MemberDisplayName", "", AggregateFunction.None);
    _fields.DefineField(TaskFieldIndex.StatusID, 17, "StatusID", "", AggregateFunction.None);
}

Designer version is 1.0.2004.2 Final (released May 26th, 2005). Thanks in advance for any thoughts you may have.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 22-Sep-2005 13:47:33   

Ok, that's a version which has a bug. Could you please upgrade to the latest designer? You can do that by simply downloading the Designer core assemblies from the upgrades section in the customer area.

It might be you've to set the relations to alternatives and back to get the right set back to fix the results of the bug in this older version. You'll notice as well that you can now pick more alternatives.

Frans Bouma | Lead developer LLBLGen Pro
bmoeskau
User
Posts: 54
Joined: 15-Jun-2005
# Posted on: 22-Sep-2005 17:01:55   

I downloaded the latest runtimes but I'm still getting the exact same emitted code. rage I went into the designer and rebuilt my relations and fields and nothing changed. Am I doing something wrong at that point? I really don't understand what the relation requirements are, other than I made sure that each table was joined by at least one key so that there is a path that traverses each table.

I'm not sure why you are limited to only choosing certain relations (unlike entity collections that seem to give you access to all relations without having to pre-choose). Also, it's unclear to me if selecting columns from specific tables is intended to affect the outcome. For example, my TaskMember relation table only exists to join Task to Member. Both of its keys already exist in the primary tables. It is obviously needed for the relations, but when I'm choosing columns, does it matter whether I pick MemberID from Member or TaskMember? Can I have the table just in the relation but not pick columns from it? How does the order of the relations come into play? The documentation is not clear on this.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 22-Sep-2005 18:10:17   

bmoeskau wrote:

I downloaded the latest runtimes but I'm still getting the exact same emitted code. rage I went into the designer and rebuilt my relations and fields and nothing changed. Am I doing something wrong at that point? I really don't understand what the relation requirements are, other than I made sure that each table was joined by at least one key so that there is a path that traverses each table.

The relations have to be stored in a chain. A - B B - C C - D

not: A - B C - D B - C

Normally this should go OK automatically. The designer should make sure this is always the case. I'm surprised it still doesn't work. Could you please mail me the .lgp file? (support AT llblgen.com), and I'll have a look. If possible, please let me know the order of the actions you took to produce the typed list which goes wrong

I'm not sure why you are limited to only choosing certain relations (unlike entity collections that seem to give you access to all relations without having to pre-choose). Also, it's unclear to me if selecting columns from specific tables is intended to affect the outcome. For example, my TaskMember relation table only exists to join Task to Member. Both of its keys already exist in the primary tables. It is obviously needed for the relations, but when I'm choosing columns, does it matter whether I pick MemberID from Member or TaskMember?

That doesn't matter, they're the same value

Can I have the table just in the relation but not pick columns from it?

yes, that;s why you first select the entities you want to build the typed list on. That will give a total list of fields, then you select the fields from THAT list which form the typed list. it's similar to SELECT A.* FROM A join B

Here you select A's fields, and add A and B to the list.

How does the order of the relations come into play? The documentation is not clear on this.

The order of the relations is transparent to you, it should work automatically. The entities you add to the typed list then form the list of relations (it will pick one automatically), you can select another one if you like, from the list. The list of relations form a connected graph, and the code generated should work as expected, the designer should define the relations in teh right order for you.

Frans Bouma | Lead developer LLBLGen Pro
bmoeskau
User
Posts: 54
Joined: 15-Jun-2005
# Posted on: 22-Sep-2005 20:49:52   

OK -- after realizing that you said to upgrade the DESIGNER binaries, not the backend runtime libraries, it seems to be working now. Just upgraded the designer, regen'ed and everything is golden. I have less hair than I started out with, but it is working, so that's the important thing wink I guess I'll check the updates page next time BEFORE punching my computer for hours on end...

I've said it before, just like everyone else -- thanks so much for your immediate feedback Frans! Keep up the great work.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 22-Sep-2005 22:12:48   

Glad it's sorted out! smile

Frans Bouma | Lead developer LLBLGen Pro