I've run into a problem with using the FieldCompareSetPredicate object throwing cast exception errors. Any help would be appreciated.

Dim fieldIn As EntityField2 = TblAFields.EventId.SetObjectAlias("d")
Dim fieldSet As EntityField2 = TblAFields.EventId.SetAggregateFunction(AggregateFunction.Max)

Dim inClause As IPredicate = _ 
                       New FieldCompareSetPredicate(fieldIn, fieldSet, SetOperator.In, Nothing)

'I have also tried it like this
Dim inClause As IPredicate = _ 
                       New FieldCompareSetPredicate(TblAFields.EventId.SetObjectAlias("d"), _ 
                      TblAFields.EventId.SetAggregateFunction(AggregateFunction.Max) _
                      , SetOperator.In, Nothing)

The error thrown is this: Unable to cast object of type 'SD.LLBLGen.Pro.ORMSupportClasses.EntityField2' to type 'SD.LLBLGen.Pro.ORMSupportClasses.IEntityField'.

However another entity works fine with this code:

Dim inClause As IPredicate = New FieldCompareSetPredicate(TblDFields.DocId.SetObjectAlias(docTable), Nothing, TblRFields.DocId, Nothing, SetOperator.In, subFilter, relationsIN)

I may be missing something obvious here, but it seems that for different overloads I get different behaviour which just doesn't make sense.

I am using Version 2 of LLBLGen.

Some overloads should be used with the Adapter model, and others should be used for the SelfServicing model.

Those with IEntityField2 parameters are for Adapter, and those with IEntityField parameters are for SelfServicing.

It's stated in the LLBLGenPro Reference manual, which method is specific to which template group (model).

By implication then, the FieldCompareSetPredicate has no IEntityField2 overloads and can't be used with the Adapter model ?

If that is the case then it doesn't explain why this works

Dim inClause As IPredicate = _ 
                     New FieldCompareSetPredicate(fieldIn, fieldSet, SetOperator.In, _ 
new FilterExpression())

and

Dim inClause As IPredicate = _ 
                     New FieldCompareSetPredicate(fieldIn, fieldSet, SetOperator.In, Nothing)

doesn't work. I am using the Adapter model.

Maybe I should be looking at the IEntityFieldCore overloads on the constructor as these appear to be Adapter specific? Btw I have downloaded the LLBLGen Pro reference manual and appears to be corrupted - I can see the Index area by when I click on any link, the content is showing Action Cancelled

Oh, I'm sorry.... IEntityField2 inherits from IEntityFieldCore.

So the folloiwng overloads are for the Adapter:

FieldCompareSetPredicate Constructor(IEntityFieldCore,IFieldPersistenceInfo,IEntityFieldCore,IFieldPersistenceInfo,SetOperator,IPredicate) Creates a new FieldCompareSetPredicate instance.   

FieldCompareSetPredicate Constructor(IEntityFieldCore,IFieldPersistenceInfo,IEntityFieldCore,IFieldPersistenceInfo,SetOperator,IPredicate,Boolean) Creates a new FieldCompareSetPredicate instance.   

FieldCompareSetPredicate Constructor(IEntityFieldCore,IFieldPersistenceInfo,IEntityFieldCore,IFieldPersistenceInfo,SetOperator,IPredicate,IRelationCollection) Creates a new FieldCompareSetPredicate instance.   

FieldCompareSetPredicate Constructor(IEntityFieldCore,IFieldPersistenceInfo,IEntityFieldCore,IFieldPersistenceInfo,SetOperator,IPredicate,IRelationCollection ,Boolean) Creates a new FieldCompareSetPredicate instance.   

FieldCompareSetPredicate Constructor(IEntityFieldCore,IFieldPersistenceInfo,IEntityFieldCore,IFieldPersistenceInfo,SetOperator,IPredicate,IRelationCollection, String) Creates a new FieldCompareSetPredicate instance.   

FieldCompareSetPredicate Constructor(IEntityFieldCore,IFieldPersistenceInfo,IEntityFieldCore,IFieldPersistenceInfo,SetOperator,IPredicate,IRelationCollection, String,Boolean) Creates a new FieldCompareSetPredicate instance.   

FieldCompareSetPredicate Constructor(IEntityFieldCore,IFieldPersistenceInfo,IEntityFieldCore,IFieldPersistenceInfo,SetOperator,IPredicate,IRelationCollection, String, Int64,ISortExpression) Creates a new FieldCompareSetPredicate instance.   

FieldCompareSetPredicate Constructor(IEntityFieldCore,IFieldPersistenceInfo,IEntityFieldCore,IFieldPersistenceInfo,SetOperator,IPredicate,IRelationCollection, String, Int64,ISortExpression,Boolean) Creates a new FieldCompareSetPredicate instance.   

FieldCompareSetPredicate Constructor(IEntityFieldCore,IFieldPersistenceInfo,IEntityFieldCore,IFieldPersistenceInfo,SetOperator,IPredicate,IRelationCollection, String,Int64,ISortExpression,Boolean,IGroupByCollection) Creates a new FieldCompareSetPredicate instance.   

FieldCompareSetPredicate Constructor(IEntityFieldCore,IFieldPersistenceInfo,IEntityFieldCore,IFieldPersistenceInfo,SetOperator,IPredicate,String) Creates a new FieldCompareSetPredicate instance.   

FieldCompareSetPredicate Constructor(IEntityFieldCore,IFieldPersistenceInfo,IEntityFieldCore,IFieldPersistenceInfo,SetOperator,IPredicate,String,Boolean) 

Thank you for you patience. You are right. I really have to pay careful attention to the model that the overloads relate to. I concede that once you get the hang of it, it does get easier, but I also think there is room to improve the class organisation in the product. For example, maybe all adapter specific overloads could be grouped in once class for the predicate types to make it easier to work with.

What is frustrating is that these errors are not trapped at compile time, which would save a lot of time? But then I suppose that is what unit tests are for.

That would result in 2 classes, which we wanted to avoid.

The extra persistenceinfo parameter isn't a requirement if there aren't operator overloads affecting the class, as is the case with FieldCompareSetPredicate. However to keep things consistent we kept the persistenceinfo parameter.

From a product point of view I agree that two classes are not ideal. Maybe an option then would be to simply add a task to the generator to add a wrapper class to provide the seperation of models.

Is this feasible?

sbense wrote:

From a product point of view I agree that two classes are not ideal. Maybe an option then would be to simply add a task to the generator to add a wrapper class to provide the seperation of models.

Is this feasible?

Wouldn't that add just more confusion? I mean: there's always this FieldCompareSetPredicate class, then there are generated wrappers...

I agree that the class's CTor isn't ideal as in: it's set of overloads is big and vs.net doesn't help either as the tooltips simply can't stay on the overload you're already on (read: the tooltip is simply retarded).

Otis wrote:

Wouldn't that add just more confusion? I mean: there's always this FieldCompareSetPredicate class, then there are generated wrappers...

There is already confusion I mean you could just have FieldCompareSetPredicate and FieldCompareSetPredicate2 to follow the current model conventions. And I totally agree about the tooltips in VS. That just adds to the problem. From a development point of view, I look at the FieldCompareSetPredicate and expect it to provide just that, without having to consider the model based on overload conventions.

I still think the seperation between models - Adapter/SS should be class orientated and not based on picking the correct overloads. Of course once you have picked the right ones and unit tested the job is done. Anyway thanks for the thoughts.

If I could start over, I definitely would do it differently BUt splitting it up now isn't doable, as it would break a lot of code.

Otis wrote:

If I could start over, I definitely would do it differently BUt splitting it up now isn't doable, as it would break a lot of code.

Don't flame me for this but is v3.0 planned as a logical extension to v2.5 with the Linq stuff etc. or is v3 planned to be a 'new' version based on v2.5 but not necessarily backwards compatible?

Cheers Simon

I'm not answering for Frans, but I think any new version should be backward compatible (at least to a some extent), with limited break changes. To allow for smooth upgrades.

Walaa wrote:

I'm not answering for Frans, but I think any new version should be backward compatible (at least to a some extent), with limited break changes. To allow for smooth upgrades.

Exactly. It's always wise to take a page from MS's Book of Errors(tm). Take for example the early betas of vs.net 2005. They broke a lot of stuff in asp.net, people were very unhappy. They made it a bit smoother, but it was still a pain. When there's no upgrade path that is smooth, people are reluctant to upgrade, so the upgrade path is essential.

v3 will have a new designer, and a continuation of the v2.5 framework. All templates will be re-done though, but I already said too much already so to avoid waking the competitors, I will not say more

Otis wrote:

Walaa wrote:

I'm not answering for Frans, but I think any new version should be backward compatible (at least to a some extent), with limited break changes. To allow for smooth upgrades.

Exactly. It's always wise to take a page from MS's Book of Errors(tm). Take for example the early betas of vs.net 2005. They broke a lot of stuff in asp.net, people were very unhappy. They made it a bit smoother, but it was still a pain. When there's no upgrade path that is smooth, people are reluctant to upgrade, so the upgrade path is essential.

v3 will have a new designer, and a continuation of the v2.5 framework. All templates will be re-done though, but I already said too much already so to avoid waking the competitors, I will not say more

No problem at all with your and Walaa's answers for your future plans. I thought that might be the case.

However, it doesn't always have to be done like that. DevExpress for example (and SyncFusion similarly I believe) have two concurrent streams with a view to phasing one out over time. So DevExpress v7.xx is the latest and greatest and gets all the best new features. It was originally based on v6.xx but now only supports .NET 2.0 v6.xx supports .NET 1.1 as well as 2.0 and is maintained with bug fixes etc. but as far as I know there are no new main features going to be added. So existing customers running .NET 1.1 will get support and maintenance releases but no major new functionality. When new projects start, they would start with the v7.xx product. So DevExpress gets to concentrate on .NET 2.0 (and higher) development but existing customers are not ignored.

I think you have mentioned in a number of threads that "If I could start over, I definitely would do it differently BUt splitting it up now isn't doable, as it would break a lot of code.". If that were ever to happen, then a major version release is the time to do it and I was just wondering whether that was in the works but its certainly not a problem if it isn't.

I think you have mentioned in a number of threads that "If I could start over, I definitely would do it differently BUt splitting it up now isn't doable, as it would break a lot of code.". If that were ever to happen, then a major version release is the time to do it and I was just wondering whether that was in the works but its certainly not a problem if it isn't

There are certainly cases where starting over has been a disaster, Navigator for example. But I believe there are also times for breaking changes, a clean slate, and a fresh design based on what I know now that I wished I knew then. The decision on which, when is a dangerous one for a business. The process on deciding which is appropriate at a point in time has to involve a long term vision, with sorter term planning that plans out at least roughly how to get there via evolution or revolution.

simmotech wrote:

Otis wrote:

Walaa wrote:

I'm not answering for Frans, but I think any new version should be backward compatible (at least to a some extent), with limited break changes. To allow for smooth upgrades.

Exactly. It's always wise to take a page from MS's Book of Errors(tm). Take for example the early betas of vs.net 2005. They broke a lot of stuff in asp.net, people were very unhappy. They made it a bit smoother, but it was still a pain. When there's no upgrade path that is smooth, people are reluctant to upgrade, so the upgrade path is essential.

v3 will have a new designer, and a continuation of the v2.5 framework. All templates will be re-done though, but I already said too much already so to avoid waking the competitors, I will not say more

No problem at all with your and Walaa's answers for your future plans. I thought that might be the case.

However, it doesn't always have to be done like that. DevExpress for example (and SyncFusion similarly I believe) have two concurrent streams with a view to phasing one out over time. So DevExpress v7.xx is the latest and greatest and gets all the best new features. It was originally based on v6.xx but now only supports .NET 2.0 v6.xx supports .NET 1.1 as well as 2.0 and is maintained with bug fixes etc. but as far as I know there are no new main features going to be added. So existing customers running .NET 1.1 will get support and maintenance releases but no major new functionality. When new projects start, they would start with the v7.xx product. So DevExpress gets to concentrate on .NET 2.0 (and higher) development but existing customers are not ignored.

We do that too though: we release a new version and keep supporting the older ones, till some point. V3 will for example see the abandonement of .net 1.x code, we won't continue with that in v3, but we'll keep supporting v1 and v2 as there are still users with these tools.

With v2.0, it was too fresh IMHO to cut out .net 1.x, so we kept that (which did add a lot of work though). However I do believe that you should provide a smooth upgrade path, or at least try to make it as smooth as possible.

I think you have mentioned in a number of threads that "If I could start over, I definitely would do it differently BUt splitting it up now isn't doable, as it would break a lot of code.". If that were ever to happen, then a major version release is the time to do it and I was just wondering whether that was in the works but its certainly not a problem if it isn't.

We did try in v2.0 development to migrate selfservicing and adapter to one codebase where selfservicing is actually a wrapped adapter (functionality wise, that's perfectly doable).

However, we came to the point that we had interface clashes and we had to make a choice: break a lot of code or stop with the migration. We decided to stop the migration and take it as it is: it's unfortunate that for example adapter was developed after selfservicing, but that's the way it is, so IF I could start over, it would look completely different, but the choice to do so is IMHO not there: it would break so much code and also beyond a given level of pain. Take for example the named collections in selfservicing. I really want to get rid of them, but that's not really possible, as it would make it impossible to migrate a v2 app to a v3 app

I also think that if we would have decided to make the changes and actually write a complete new api, we wouldn't have seen a lot of people upgrading as it would mean so much work...

Otis wrote:

We did try in v2.0 development to migrate selfservicing and adapter to one codebase where selfservicing is actually a wrapped adapter (functionality wise, that's perfectly doable). ... Take for example the named collections in selfservicing. I really want to get rid of them, but that's not really possible, as it would make it impossible to migrate a v2 app to a v3 app ... I also think that if we would have decided to make the changes and actually write a complete new api, we wouldn't have seen a lot of people upgrading as it would mean so much work...

I think thats what I was asking about.

v2.5 is a pretty complete solution now so I was wondering whether you were going to take the opportunity in v3.0 to jettison the current SelfServicing codebase and 'swap' it around to make it a wrapped adapter instead - existing SelfServicing users stay with v2.x but can use v3.x for new projects etc.

Plus, if you're doing that there is also the opportunity (and maybe additional development time if there is to be an intermediate v2.6 too) to change anything where you wish you had known then what you know now - hindsight is an exact science.

A new API (and it doesn't have to be completely different) would still be appealing for your existing customers, especially when you give quotes like "but I already said too much already so to avoid waking the competitors, I will not say more :)"

Cheers Simon

simmotech wrote:

Otis wrote:

We did try in v2.0 development to migrate selfservicing and adapter to one codebase where selfservicing is actually a wrapped adapter (functionality wise, that's perfectly doable). ... Take for example the named collections in selfservicing. I really want to get rid of them, but that's not really possible, as it would make it impossible to migrate a v2 app to a v3 app ... I also think that if we would have decided to make the changes and actually write a complete new api, we wouldn't have seen a lot of people upgrading as it would mean so much work...

I think thats what I was asking about.

v2.5 is a pretty complete solution now so I was wondering whether you were going to take the opportunity in v3.0 to jettison the current SelfServicing codebase and 'swap' it around to make it a wrapped adapter instead - existing SelfServicing users stay with v2.x but can use v3.x for new projects etc.

Plus, if you're doing that there is also the opportunity (and maybe additional development time if there is to be an intermediate v2.6 too) to change anything where you wish you had known then what you know now - hindsight is an exact science.

Hehehe Yes, I do think you are right in some regard. The thing we are facing as well is the o/r stuff coming from redmond in orcas. We've to counter that too. Breaking stuff is alienating customers so it might be that they're then moving to MS' stuff perhaps, but it is worth a consideration.

A new API (and it doesn't have to be completely different) would still be appealing for your existing customers, especially when you give quotes like "but I already said too much already so to avoid waking the competitors, I will not say more :)" Cheers Simon

I know myself a little bit and I always babble too much about stuff I'm a little bit excited about and although I do believe development in the open is good, I know that a couple of competitors read these forums, so I better keep my mouth shut for a couple of months . I've to see how big the impact will be but it might be not that big, you made good points