I admit I've found this question asked before (#2811), but I'm asking again hoping something has changed since 5.2.
What is the recommended approach to adding additional properties/columns (beyond two PKs) to a link table created by a many-to-many navigation collection?
I have a pretty simple use case: an entity/table of Parts and an entity/table of Assemblies. The link table defines which parts go to an assembly (bill of materials), but I also need to include how many of each part are in the assembly. The obvious solution is to add a "Quantity" column to the table joining PartId and AssemblyId, but what's not obvious is how to do that via Suite, or via customization that isn't wiped out by a later Suite-initiated code generation.
I understand the availability of Object Extensions to extend objects managed by modules, but as the Object Extensions page points out, this shouldn't be necessary with my own classes.
Are Object Extensions still the recommended approach to this? Can you provide a complete example of using Object Extensions in this application? I honestly find it hard to believe this isn't a standard feature at this point. At the very least, a method is needed to prevent the overwriting of CRUD object customizations when, for example, a new property is added. As it stands now, it seems I have one chance to get an entity perfect in Suite before I customize and can no longer touch it.
4 Answer(s)
-
0
hi
I suggest you use EF's way of implementing it instead of
Object Extensions. It's not designed for this.The suite may not support some special cases. You have to do it manually.
-
0
Thanks for the response.
I expected to hear suite is not capable because I couldn't find the feature, but I would disagree that this is a special case; in my experience this is a pretty common scenario.
Either way, you suggested using EF's method of implementation instead of Object Extensions. Can you point to an example or documentation?
Using EF's method, is it still possible to use suite to maintain the primary entities (parts and assemblies in my case)? Or, do I have to abandon suite altogether to avoid overwriting changes?
-
0
I understand that what I originally asked essentially amounted to a feature request, and I've now seen (and upvoted) the requests for these features in #3052, but what I need today is some direction on moving forward without the features. Is there a sample somewhere of a many-to-many relationship with "payload" added in ABP? I've read the Microsoft Documentation on the subject, but I'm trying to marry that with the ABP Suite workflow and hopefully end up with code that is compatible with how you intend to implement the partial class / "code updater" discussed here.
Maybe point me to the internal feature issue that was created to persist CRUD customizations through regenerations? At least I can try to manually mimic that technique.
-
0
I think you can add properties to
AssemblyPart. Of course you will need many changes in the generated code.
