Solution from the S30962 suggestion - Collections are not visible in reports.

Hello Noxe,
Thank you for the update. Unfortunately, there is no good news for you in this regard. We are preparing the next 9.1 release and at the moment we have not found a good solution for you. The collections are not shown in the reports designer because of XPO design: Reports - Collection properties not marked with the Association attribute should be visible in the report designer (ObjectModelBrowser tree).
We have an idea to try to reuse XPO association lists in XAF but this requires additional testing from our side. We are working on forcing this to work in XAF.
Thank you for your patience,
Dennis

Hi Dennis,
thanks for the Info - please keep in mind that this Problem is really urgent(we are fighting now really long starting with the performance problem, the workaround and the resulting problems now)! Also, it is not only the Reports - also in the Pivot/Analyses Module - and in general, they are not visible in the Object Model Field picker!
thx

Hello,
Thanks for the update, Noxe. Unfortunately, we have no good news for you. The current solution doesn't work due to a limitation of XPO: Weak associations as member collections. Once it is implemented you will be able to bind your collections everywhere.
One possible solution for you is to wait until the Performance - Support fast operation with large amount of data in a nested and lookup List View (turn on server mode) is implemented in XAF. Our developers have already started its implementation and this feature will be ready for the 9.2. release. We cannot publish it in the 9.1 release because we need some changes made from our XPO Team and also we need more testing. Please accept our apologies for the inconvenience.
Thanks,
Dennis

Not good Dennis, not good - this means we have no solution till July,August or even September…
At all this means that with starting the Original Post on 10/23/2008 it takes us nearly a half year to avoid Performance Problems, and another half year to get around the problems which comes now with the workarounds… I still cannot understand why this is not a high priority Bug/Issue
No comment

Hello Noxe,
Thank you for the feedback. All our products are designed to work in certain scenarios and all the scenarios have their limitations. Working with large M-M collections in XPO has some limitations which can be bypassed, for example, by creating intermediate link class. Unfortunately, XAF is designed to produce the default UI only for default constructed M-M relationships, and doesn't produce the default UI when working via intermediate links. This default behavior meets the needs of the majority of our customers, and we have not had any complains regarding this. This means that our clients do not have the real scenarios in which they needed to have M-M collections with millions objects on one side. Our framework's goal is to meet the needs of the most people, and it seems it does that well. To tell you the truth, a scenario where you have hundreds of thousands of contacts in the detail collection seems specific to us, and we do not recommend you design your BM this way. Obviously, our products do not handle your specific scenario well, and this is its limitation. We do not hide this.
As I have already said above, we have several suggestions in this regard, and what we have is actually what we have at the moment. We understand this and apologize for all the inconvenience here, but this is all that we can offer, at the moment.
Please feel free to contact/ call us directly or email us at management@devexpress.com if you want to provide more feedback on our products, services, and this issue in particular. We would be glad to hear from you.
Thanks you for your patience,
Dennis

Hi Dennis,
thx for your detailed Info - i think i just have to wait now. But please explain me this Statement:
<<To tell you the truth, a scenario where you have hundreds of thousands of contacts in the detail collection seems specific to us, and we do not recommend you design your BM this way>>
We have an Contact Class, and an ContactKind Class. An Contact can have more ContactKinds - and an ContactKind can be assigned to many Contacts - so this is a typical M-M Relation - and if you have 100000 Contacts then you have minimal 100000 M-M Records (ContactKind is mandatory). So please tell me where here is an wrong BO Design and i change it!?
thx
Noxe

Hello Noxe,
>>
We have a Contact Class, and an ContactKind Class. A Contact can have more ContactKinds - and a ContactKind can be assigned to many Contacts - so this is a typical M-M Relation - and if you have 100000 Contacts then you have minimum of 100000 M-M Records (ContactKind is mandatory). So, please tell me what is wrong here with the BO Design and I will change it.
<<
Yes, it is a typical M-M relationship but it should not be accomplished this way in cases where you have very large collections, as in your case. From our experience in building business applications your current model for this business case is not correct. This relationship should be accomplished by creating an explicit link, for example, as described here: OBSOLETE - How to use an associated IList collection for a Many-To-Many relationship to avoid performance problems when working with large collections.. I have already told you about this approach several times in the past.
Another approach is described here: OBSOLETE - How to create a wrapper around a Many-To-Many relationship to avoid performance problems when working with large collections..
Unfortunately, these solutions have limitations on their use in XAF reports by default, because you cannot use these weak members in the Field List.
Thanks,
Dennis

Hi Dennis,
i know the workarounds and we have implemented them.
<<From our experience in building business applications your current model for this business case is not correct. >>
What is the correct way Dennis!?

Noxe, have you read my entire answer? They show you the right way to design your business model. Actually, this is the workaround I provided you, and which, as you said, is already implemented.
Thanks,
Dennis

Dennis,
it sounded to me that you wanted to say that our Business Class Model is wrong - if so what should we change…?
The workarounds are implemented(ManytoManyHelper and so on) - so at all for us there is no official DX Way in XAF to solve it actually with our BO Model(wrong designed?) - I know that there is currently no solution, but it sounds always that we make our BO wrong?
Currently with our Project Plan i can cover the time till 9.2, and i hope its a good then - but please just clarify your means to the BO Model.
thx
Noxe

Noxe, thanks for the update. It seems that there is some sort of misunderstanding between us…
Initially you wrote the following: "We have a Contact Class, and an ContactKind Class. A Contact can have more ContactKinds - and a ContactKind can be assigned to many Contacts - so this is a typical M-M Relation - and if you have 100000 Contacts then you have minimum of 100000 M-M Records (ContactKind is mandatory). So, please tell me what is wrong here with the BO Design and I will change it."
Please take special note of the "typical" word there. It sounded to me that you have implemented this in the way that is described in the documentation, i.e. without any link classes, helpers, etc. This would be wrong for your case, because it is better to implement this relation with an intermediate link, or at least helpers we suggested before. That is why I said that your "typical" implementation is wrong here.
Now you've written the following: "The workarounds are implemented(ManytoManyHelper and so on)". Well, I am glad to hear this, because this means that you followed my suggestion and implemented your relation right, via an intermediate link, helpers, etc. This is good and your BM is correct in this case.
So, our misunderstanding was caused by the "typical" word and may be my failure. I apologize for the inconvenience in any case.
Thanks,
Dennis

hi dennis,
Now everything is clear! I thought you know that, because anatol created this post based on the original performance post.
So i will wait now for the 9.2 - i hope it will solve all problems.
I wish you a good weekend dennis!
Greets
Noxe

Thank you, Noxe, you too!
Regards,
Dennis

Hi Dennis,
Is this implemented in 9.2?

Hello Noxe,
Thanks for the update. Unfortunately, we have not implemented this suggestion yet. Please continue tracking to receive automatic notifications about its state.
We have some positive results, however. It is possible to override the following method within your persistent class to provide the server collection for your details collection:

C#
protected override IList CreateAssociationList(XPMemberInfo memberInfo) {  
            if(memberInfo.Name == "NonAggregatedOneToManyCollection") {  
                XPServerCollectionSource serverCollectionSource = new XPServerCollectionSource(Session, memberInfo.CollectionElementType, null);  
                serverCollectionSource.AllowEdit = true;  
                serverCollectionSource.AllowNew = true;  
                serverCollectionSource.AllowRemove = true;  
                serverCollectionSource.FixedFilterCriteria = new BinaryOperator(memberInfo.GetAssociatedMember().Name, this);  
                return ((IListSource)serverCollectionSource).GetList();  
            }  
            else  
            {  
                return base.CreateAssociationList(memberInfo);  
            }  
        }  

Then the GridListEditorController will automatically configure the grid to work in the Server Mode. Please let me know in case of any difficulty.
Thanks,
Dennis

Hi Dennis,
very bad that this suggestion also dont get it into the 9.2… (as you know my performance problem started at 10/2008) Does your workaround now solve our ManyToMany Problem - does it replace the ManytoManyHelper and can i use the collection then as normal (reports and so on…)
greets
Noxe

Hello Noxe,
Unfortunately, this solution doesn't solve the problem with binding details collections in reports and other places. It can be used with the many-to-many relationship, but I believe that the solution you have now with the helper class we provided is more convenient than this one. Using this approach, the details collections will be read-only in the master DetailView.
I have prepared a small example for version 9.1. It shows how to write the code and also demonstrates the limitations.
We do not have another solution or news when the suggestion about server mode in nested list views is implemented. Please track it to be automatically notified about changes with its status. Thanks for your great patience.
Please let me know if you have additional questions.
Thanks,
Dennis

Hi Dennis,
i just wanted to test your suggestion about CreateAssociationList, but this Method is never called? I have this property in my class:
        [Aggregated, Association("Mailing-MailingContacts")]
        public XPCollection<MailingContact> MailingContacts
        {
            get
            {
                return GetCollection<MailingContact>("MailingContacts");
            }
        }
it has many Records - about 8000 - for that collection i want to activate the servermode for the DetailView.

Hello Noxe,
Thanks for the update. Use the generic version of this method. Also, check the "Discussion (beta)" tab of this web page in the online Support Center to see a similar discussion on our forum. There, Jascha had the same problem…
Let me know if I can assist you further.
Thanks,
Dennis

Ohh ok - i understand now - this dont work with an XPCollection…
Is there no way to activate the ServerMode for an DetailView Collection?

Hi Dennis,
ServerMode works now - but now i get an exception if i save the Master:
Eine Ausnahme (erste Chance) des Typs "System.NotSupportedException" ist in DevExpress.Xpo.v9.2.dll aufgetreten.
19.08.09 20:33:19.607     ================================================================================
The error occured:
     Type: NotSupportedException
     Message: Die angegebene Methode wird nicht unterstützt.
     Data: 0 entries
     Stack trace:
   bei DevExpress.Xpo.Helpers.XpoServerCollectionAdderRemover.CopyTo(Array array, Int32 index)
   bei DevExpress.Xpo.Helpers.XpoServerCollectionWrapperBase.CopyTo(Array array, Int32 index)
   bei System.Collections.ArrayList.InsertRange(Int32 index, ICollection c)
   bei System.Collections.ArrayList.AddRange(ICollection c)
   bei DevExpress.ExpressApp.Validation.ValidationTargetObjectSelector.FindAggregatedObjects(Object owner)
   bei DevExpress.ExpressApp.Validation.ValidationTargetObjectSelector.GetObjectsToValidate(Session session, Object currentObject)
   bei DevExpress.ExpressApp.Validation.PersistenceValidationController.ObjectSpace_Committing(Object sender, CancelEventArgs e)
   bei System.EventHandler`1.Invoke(Object sender, TEventArgs e)
   bei DevExpress.ExpressApp.ObjectSpace.OnCommitting(CancelEventArgs args)
   bei DevExpress.ExpressApp.ObjectSpace.CommitChanges()
   bei DevExpress.ExpressApp.Win.SystemModule.WinDetailViewController.SaveAndClose(SimpleActionExecuteEventArgs args)
   bei DevExpress.ExpressApp.SystemModule.DetailViewController.saveAndCloseAction_OnExecute(Object sender, SimpleActionExecuteEventArgs e)
   bei DevExpress.ExpressApp.Actions.SimpleAction.RaiseExecute(ActionBaseEventArgs eventArgs)
   bei DevExpress.ExpressApp.Actions.ActionBase.ExecuteCore(Delegate handler, ActionBaseEventArgs eventArgs)

Hello Noxe,
Thanks for the feedback. I did not see this problem before, though perhaps it is because I tested the sample incorrectly. I will check it again and will test the scenario that crashes the application, as in your case.
Regarding alternatives, this seems to be the easiest solution. But for now I am thinking about a filter by the master object ServerCollectionSource used for the nested list view. I have not yet had a chance to test how this will work, but I will report my results ASAP.
The idea is to override the application's CreateCollectionSourceCore method, and put in your own collection source. I think you can try this solution in the meanwhile, if you wish.
Thanks,
Dennis
P.S.
The Support Center concept does not allow multiple problems within a thread as this makes it difficult to properly track such items. Please open a new issue for each problem you want to discuss.

Hi Dennis, thx for your feedback - the problem is the PersistenceValidationController - i deactivated this controller in the meanwhile for my detailview. CreateCollectionSourceCore is a good suggestion, thx, i will play around with it.
<The Support Center concept does not allow multiple problems within a thread > - i know - i just continued to your last reply ;)

Dennis, this solution also leads in other problems.
For example i have an import module.
here i do:
Detail dt = new Detail();
master.Details.Add(dt);
Normaly the relation between Master and Details is created automaticly, mean on the Detail object the "Master" Property is filled automaticly, this is now gone - i have to manually set it now.
I also had another exception, "Adding while Grouping or Serting is active is not allowed", i dont know it exaclty right now - but this workaround leaded in more problems then usefull functionality…