Otis, This has bit me yet again. Is there any possiblity of getting this fixed/changed/enhanced?

http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=13195&HighLight=1 Walla indicated 2.6 might have something for it (which I am using now) http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=12580

Anyway, this is extremely annoying. No other place in all of LLBLGen do I have to be concerned if a collection is saved or not when determining what predicate to use. This basically comes up when I try to use an EntityView and subtype predicates...

Ugh....

Frans, has posted the code to get this working and he clearly stated it will not be added in v.2.6 (so he did override what I've said in the older thread).

Do you have any problem with Frans' code?

No, just a problem in general with this being different than every other thing in LLBLGen. And therefore it constantly biting me as a developer.

Why would this predicate not work on the object in memory. I still think this is silly.

I explained that in the thread linked above. I also showed with a oneliner how you can do it.

Argh...I know how to do it. That is not the point. As far as that goes, I can use LINQ, I can loop through the collection doing an 'if' statement....etc...

The point is the following:

new EntityView<MyEntity>(somecollection, ANY PREDICATE YOU WANT)

works just fine......except for one predicate that the framework generates for you! That has bitten me SEVERAL times and I thought you wanted to make this easy for the developer and make it where these little things cannot creep in on us at runtime...

yes, that's right. The thing is... the generated predicate can't be altered to use in-memory for all cases, so it's for DB only. That's the sad part of it.

This leaves two options: - generate one for memory usage as well or - leave it and let the developer write the single line.

The option to generate a predicate which was easy to create, was a bit redundant to me because to use in-memory filtering on types one had to pick the other generated predicate anyway. So what you want, to use the generated filter for in-memory usage as well is not possible unfortunately, so whatever I do: you have to pick another predicate so IMHO the problem really is: to remember that you have to do that.

To elaborate a bit on why the predicate can't be re-used in-memory: it needs a different predicate for in-memory usage, but the called code doesn't know it's for in-memory usage, hence the problem.

A normal predicate that compared a field, would look at the property of the entity.

This is a single table hierarchy....why can't the generated filter simply look at discriminator value used in the hierachy?

WayneBrantley wrote:

A normal predicate that compared a field, would look at the property of the entity.

This is a single table hierarchy....why can't the generated filter simply look at discriminator value used in the hierachy?

Because the method is general for all hierarchy types not just for targetperentityhierarchy.

Wouldn't it be easy to have that method be specific to the hierarchy type in the generated code? If single table hierarchy output the code one way and in multi output it another way. At least this way it would work in cases..

I dont know....just did not want to get bitten anymore.

BTW, when are we to see any official announcements concerning feature lists or CTP or whatever of anything new?

WayneBrantley wrote:

Wouldn't it be easy to have that method be specific to the hierarchy type in the generated code? If single table hierarchy output the code one way and in multi output it another way. At least this way it would work in cases..

I dont know....just did not want to get bitten anymore.

I understand, though I don't think I can give a proper solution here, as last time I tried it wasn't really solvable properly ... Just use as rule of thumb:in-memory filtering is something else than db filtering: type filters aren't working the way they do in the db.

BTW, when are we to see any official announcements concerning feature lists or CTP or whatever of anything new?

Not before may 2009 I think. development is going very well (and the designer will support grouping (already fully working), I think you wanted to know that ) though as we want to have a lot of features in the designer and want to integrate both the project converter and templatestudio into the designer as well, it will take a while before anything substantial is available. We'll announce a closed beta program when we think we're nearing beta phase, and customers can then apply for a beta position, and if accepted, beta-testers will get access to earlier builds of the new code, and will receive a free license afterwards if they've provided feedback. It will be very cool so I think it's worth the wait.