Determining whether collection contains entity

Posts   
 
    
Posts: 134
Joined: 04-Mar-2005
# Posted on: 25-Apr-2005 17:22:12   

I'm trying to determine whether an existing collection already contains an entity before adding (to prevent dupes). I'm "merging" two entity collections, so the entities to be compared won't be exactly identical, however I can determine a dupe based on a number of attributes (ContactID and RoleID in the example below). I see the "contains" method but I'm unclear how that method determines a match. Is it on all fields of an entity, or only the primary key? The collection to be merged is the resolver of a m:n relationship:

Contact -ID -Name ...

Project -ID -Name ...

m:n -ID -ProjectID -ContactID -RoleID

If the contact is already performing a given role on a given project then I don't want to add that entity again. Is "contains" the right place to be doing this or should I be doing it some other way? confused

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39933
Joined: 17-Aug-2003
# Posted on: 25-Apr-2005 17:50:05   

Contains is a CollectionBase method which uses 'IndexOf' and IndexOf is a CollectionBase method which performs a linear search using Equals.

So it performs entity.Equals(toFind);.

Equals on an entity performs a PK field value compare. If one or both of the entities are new, an instance compare is performed.

Frans Bouma | Lead developer LLBLGen Pro
Posts: 134
Joined: 04-Mar-2005
# Posted on: 25-Apr-2005 18:30:32   

Otis wrote:

Equals on an entity performs a PK field value compare. If one or both of the entities are new, an instance compare is performed.

That's what I suspected - thanks for the confirmation.

So how would I go about doing a contains/find of an entity within an existing collection matching on a subset of the entities attributes?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39933
Joined: 17-Aug-2003
# Posted on: 25-Apr-2005 18:57:38   

Just use the PK check, thus IndexOf (or contains). As that's what you're interested in I think: if an entity is already there or not.

Frans Bouma | Lead developer LLBLGen Pro
Posts: 134
Joined: 04-Mar-2005
# Posted on: 25-Apr-2005 19:56:10   

The primary keys will be different (since I'm merging two entity collections) but there will be some fields that, as defined by the business, must not be duplicated in a collection. In the example above the same contact can't be listed twice with the same role on the same project. i.e. together the projectid, contactid, and roleid must be unique. I am merging the entitycollections between projects so I know that the projectid will differ, but I want to know whether there's already an entity in the collection with the same contactid and roleid before adding an entity to the collection. I guess I could add a unique constraint on the table (which I don't currently have) and then just try adding all the entities and catching the exception, but this seems a little odd?

Still : confused

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39933
Joined: 17-Aug-2003
# Posted on: 26-Apr-2005 12:00:37   

ChicagoKiwi wrote:

The primary keys will be different (since I'm merging two entity collections) but there will be some fields that, as defined by the business, must not be duplicated in a collection. In the example above the same contact can't be listed twice with the same role on the same project. i.e. together the projectid, contactid, and roleid must be unique. I am merging the entitycollections between projects so I know that the projectid will differ, but I want to know whether there's already an entity in the collection with the same contactid and roleid before adding an entity to the collection. I guess I could add a unique constraint on the table (which I don't currently have) and then just try adding all the entities and catching the exception, but this seems a little odd? Still : confused

If the starting point is always: check if the contact already performs a given role on a given project, you could use a little trick: create a hashtable and use the contactID as the key. As value you use a 64bit number, with the roleID shifted up 32bits and or-ed with the projectid.

Then traverse the collection once and you can check easily with the hashtable if an entity is already there or not.

Frans Bouma | Lead developer LLBLGen Pro