Hi,

Is there any way to filter a collection of entities after fetching them on the client side based on a relationship (or expression for that matter).

I cannot seem to find a way. I am trying to filter the list based on other related entities after the adapter has fetched them. I do not want to hit the database again ideally, and the list will be filtered on the client.

Regards Craig

craigmain wrote:

Hi,

Is there any way to filter a collection of entities after fetching them on the client side based on a relationship (or expression for that matter).

I cannot seem to find a way. I am trying to filter the list based on other related entities after the adapter has fetched them. I do not want to hit the database again ideally, and the list will be filtered on the client.

Regards Craig

I don't think there is a built-in way of doing this (I could be wrong), but it would be easy enough to loop through the collection and remove entities.

This can get a little tricky, as the collection members aren't typed. You will have to declare/cast them to their individual types to get their specific properties (I assume you want to filter on field values).

I can't imagine how it could be faster/better to filter on the client, though. Are you sure you can't just add a predicate and refetch?

Hi,

I cannot add a predicate and refetch. The data is arriving over the internet in a web service. It is too expensive to do the round trip.

Regards Craig

craigmain wrote:

Hi,

I cannot add a predicate and refetch. The data is arriving over the internet in a web service. It is too expensive to do the round trip.

There is no build in filtering on the client side. So you have to walk the collection and do the filtering yourself (i.e.: add the entities you want to keep to a new EntityCollection).

Alternatively, you could opt for getting the data in a datatable, and use the DataView feature of the datatable with filtering using simple expressions to filter on the client side. I'm not sure if that's an option in your scenario though.

Coincidentally I have a very similar request, although I'm happy to do the filtering server-side. I just want to make sure that I understand what you said: apart from manually building an entitycollection by looping through each entity and examining some attribute there's no way within the LLBL framework to do filtering after the entity collection has been returned from the DB server?

Correct. There is no build in client-side filtering code. You can find back entities based on the PK though, create a new entity, set the PK fields, set IsNew to false and call IndexOf.

Hi,

That really is a pitty. I think it is something that should be thought about. The indexof operator also does a linear search of the entity list, which is really inefficient considering that primary keys are present in all the tables.

I also notice that it is quite difficult to intercept the add / remove operations in an entity list so as to maintain a list of keys.

craigmain wrote:

Hi,

That really is a pitty. I think it is something that should be thought about. The indexof operator also does a linear search of the entity list, which is really inefficient considering that primary keys are present in all the tables.

It's not that inefficient as you might think, as multi-field pk's will also be usable with the same mechanism. But an index could be helpful, although it should be an index based on the hashvalue of the PK, with per hashvalue buckets with entities with the same value (as the hashvalue in .NET can only be an int)

Client side filtering requires a sort of 'view' object I think, plus if you want to do filtering, you need indexes. Adding entities and creating indexes is slow, so that's why they're not build in, as the indexes might never be used. They're on the todo list though, however there is no fixed date set when they'll be implemented.

I also notice that it is quite difficult to intercept the add / remove operations in an entity list so as to maintain a list of keys.

Keep in mind that a list of keys is hard to maintain if you have entities with a compound (multi-field) PK.