Hello,

Working with llblgen from yesterday, and testing some with a small database with little data in it, I stumbled on a very weird issue with many to one relations.

The following tables are used in this example:

User UserID (PK, Entity) Name GroupID (FK referencing Group.GroupID)

Group GroupID (PK, Entity) Name

In the table the relevant data is as follows : user: (1, Nico, 1) group: (1, Group1)

I was using the following code:

UserEntity me = new UserEntity(1);
foreach (UserEntity them in me.Group.User)
{
  Response.Write("user: "+them.Name+"<br>");
}

Hower this code printed 2 users for me, wich are exactly the same. This should not be the case, only 1 user is added to Group 1!

But when fetching the same user from the group using the below code it returned only 1 user as it should:

GroupEntity group = new GroupEntity(1);
UserEntity me = group.Gebruiker[0];
foreach (UserEntity them in me.Group.User)
{
  Response.Write("user: "+them.Name+"<br>");
}

I find this very weird, considering the fact the code basically should do the same but well, it doesn't.

I can't seem to find a Count, Length or Size in the collections either, which would be nice to have to test how many Entities it finds in a collection.

Maybe i'm doing something wrong here, but I think the code should work just fine..

Thanks in advance.

Regards, Dordanov

Collections have a Count property.

I'll check it out. It's very weird indeed.

The reason why this occurs is this:

when you do: user.Group, the group object's users collection will contain the user object, because the user and the group object have an in-memory relation, so these are true: user.Group.Contains(user); and user.Group.Users[0].Group == user.Group;

The fetch logic for collections doesn't clear nor check for duplicates already in the collection for performance reasons and to prevent to remove the related object in group.Users. This thus causes a duplicate object to be loaded in the collection, as teh action: user.Group.Users fetches all users in the group, which of course will contain the user referencing the group (and which is already in the collection), IF the user is existing in the db.

Switching on duplicate checking will slow down fetch logic, as it has to check with every object in the collection if a read object is already in the collection. I'll see how I can fix this best.

Ok, I've fixed it by 'injecting' the existing objects into the duplicate filter logic of the fetch routine (which works with double hashtables). So the fetch logic sees a duplicate and skips the object from the db, only if the object in the collection isn't new of course. As there aren't a lot of objects in the collection most of the time (if any), this is not a serious impact in performance, if at all.

I'll now perform some tests for duplicate fetching and if these succeed, I'll mail you an updated runtime library.

Ok, I don't understand all of it 100% but it's nice to hear that you could find the issue and are working on a solution

I don't need a fix right away, so if you have some more important issues to attend do those first

Thanks alot so far.

Regards, Dordanov

It's fixed. I'll mail you the new runtime.

This weekend the new installer has to be updated with the fixes currently marked as hotfixes, so it's important fixes are done before that date

Mail recieved, problem solved.

Thanks alot Frans, you rock

Regards, Dordanov