Bug Report B143532
Visible to All Users
Duplicate

We have closed this ticket because another page addresses its subject:

"Duplicate key" error trying to save roles and users

The LinkDetailViewController should not add objects in case of many-to-many association.

created 15 years ago

In http://www.devexpress.com/issue=Q234558, a solution is given to enable the New Action in case of a many-to-many assocation.
However, this unveals a bug in the LinkDetailViewController.
See Steps to Reproduce, along with the following:
The problem has to do with the fact that the DetailViewLinkController on the Child-DetailView is adding the newly created object to the Child-CollectionSource
of the Parent DetailView. However, at that moment, this Parent-Child relationShip already exists in the database.
Pressing Save and Close on the Parent's DetailView at that moment tries to insert another record in the linktable, resulting
in the constrainst-violation.
It appears to me there is a bug in the LinkDetailViewController. In the case that the CollectionSource of the ListView comes from a Many to Many association, the LinkDetailViewController should not add the newly created object to this collection, but instead reload the collection.
I will create a separate SC issue for this.
Steps to Reproduce:
Add the following controller:
public class MyWinNewObjectViewController : WinNewObjectViewController {
    public MyWinNewObjectViewController() { }
    protected override void UpdateActionState() {
        base.UpdateActionState();
        NewObjectAction.Active.RemoveItem("IsAggregatedOrOneToMany");
    }
}
Say we have a many to many relationship between Parent and Child.
Now when I Open an existing Parent, Click the New to create and Link a new Child,
Save and Close this New Child and then click Save and Close on the Parent, a Constraint Vioalation occurs.
Actual Results:
An error (constraint violation) occurs
Expected Results:
No error should occur.

Comments (1)
Dennis Garavsky (DevExpress) 15 years ago

    Hello Marco,
    >>In http://www.devexpress.com/issue=Q234558, a solution is given to enable the New Action in case of a many-to-many association.
    >>However, this reveals a bug in the LinkDetailViewController.
    I am afraid Anatol forgot to mention that this scenario is not supported out-of-the-box, and due to that, it may cause problems, like one you have found here. I do not recommend using the given solution until that feature is implemented in the product, by default.
    If you want, you can always create a suggestion to support a useful functionality which isn't present in our framework by default, so that other users can track it.
    I searched in our database and found that we already have a similar suggestion in this regard: SystemModules.Delete - Usability of ListView that represents Many-To-Many collection. Please track it. BTW, a similar suggestion was recently registered by one of our old customers: SystemModules.Link - the AllowNew and AllowDelete attributes for nested ListView should not impact the Link and Unlink actions. It's also about the behavior of ListView with for a collection property which is a part of the Many-To-Many association.
    In addition, please refer to my last post in the Inherit from an built-in Controller issue, because it contains more links to the suggestions on nested list view improvements.
    >>
    It appears to me there is a bug in the LinkDetailViewController. In the case that the CollectionSource of the ListView comes from a Many to Many association, the LinkDetailViewController should not add the newly created object to this collection, but instead reload the collection.
    I will create a separate SC issue for this.
    <<
    Marco, please create a new bug report if the problem you have found is reproducible with the default controller in the scenario, which is supported out-of-the-box in XAF. Otherwise, we cannot guarantee that this will considered to be a bug. Thanks for understanding.
    Thanks,
    Dennis

    Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

    Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.