Recently I see that there is a mismatch on how the framework handle the Master/Child relation.
The Suite merges 2 different aproches but just using one. I notice this because any time I create a Child class, the master get's a ICollection property with the child type as an intent to store the child's inside the same document but also is creating the infrastructure to store the children in a separate mongo collection (Repository, Mongo Collection, AppService, Manager, etc), unless I'm missing something we should only use one of the approaches to avoid confusion.
I spent some time trying to figure out if somehow the framework also fills the internal list but it does not.
Soo ideally, we should remove the collection from the master entity unless we plan to introduce the ability to keep children as part of the master entity for mongo projects.
6 Answer(s)
-
0
In ABP Suite, when you create a master-detail (master/child) relationship for MongoDB, the generated code currently mixes two approaches:
- The master entity gets an ICollection<TChild> property, which is typical for embedding child documents inside the master document (MongoDB's embedded documents pattern).
- At the same time, the Suite generates a separate repository, Mongo collection, and application service for the child entity, which is the reference pattern (storing children in a separate collection and referencing them from the master).
As of now, ABP Suite does not automatically synchronize or populate the internal child collection within the master entity when using the reference pattern. The infrastructure for both approaches is generated, but only the reference pattern (separate collection) is fully supported and functional.
To avoid confusion and potential data inconsistency, you should rely on the reference pattern: manage child entities via their own repository and collection, and do not use the ICollection<TChild> property on the master entity for MongoDB projects unless you plan to implement embedded documents yourself.
It is recommended to remove the ICollection<TChild> property from the master entity in your domain model for MongoDB projects, unless you specifically want to use embedded documents and handle all related logic manually.
The current behavior is a known limitation, and the recommended approach is to use only one pattern (reference) for MongoDB master-detail relationships in ABP Suite.
Sources:
- https://abp.io/docs/latest/suite/creating-master-detail-relationship
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
-
0
The current behavior is a known limitation, and the recommended approach is to use only one pattern (reference) for MongoDB master-detail relationships in ABP Suite.
This is not clear, the documentation just states that Repository, Manager and AppService are created. Not a single mention to this issue.
-
0
[daniel.meza2011@outlook.com] said:
The current behavior is a known limitation, and the recommended approach is to use only one pattern (reference) for MongoDB master-detail relationships in ABP Suite.
This is not clear, the documentation just states that Repository, Manager and AppService are created. Not a single mention to this issue.
Hi, thanks for pointing this out, and sorry for the confusion caused by the AI-bot’s initial response. You are right, Suite currently mixes two different modeling styles for master–child relations in MongoDB.
At the moment, ABP Suite generates the child entity by inheriting from
Entity(notAggregateRoot). This indicates that the child should be managed under its master (the aggregate root). However, the child entity also gets its own repository, application service, etc., as you noticed.We designed it this way intentionally. If all child-related operations were included directly in the master’s application service, that service would quickly become large and hard to maintain. Instead, we chose a more practical approach where the child entity has its own repository and application services, while the relationship with the master is still correctly established at the entity and data levels.
So yes, your observation is correct, but this was a deliberate design choice aimed at keeping the generated codebase more manageable. We have made a few adjustments to child entity generation over time, but the overall approach remains the same. That said, your suggestion makes sense, and I’ll create an issue so that we can evaluate it further.
Regards.
-
0
Hi, thanks for the clarification, the thing is that data is been stored in a separate collection and not inside the same document in case of mongo, I know that for SQL db that is a must (ef has ways to put it as a collection in the entity, but still data is in a supérate table).
So I would like to see just one approach in mongo db projects, or perhaps have the ability to decide which approach use, I think the easy path here is just remove the ICollection from the Master entity.
-
0
[daniel.meza2011@outlook.com] said: Hi, thanks for the clarification, the thing is that data is been stored in a separate collection and not inside the same document in case of mongo, I know that for SQL db that is a must (ef has ways to put it as a collection in the entity, but still data is in a supérate table).
So I would like to see just one approach in mongo db projects, or perhaps have the ability to decide which approach use, I think the easy path here is just remove the ICollection from the Master entity.
Hi, actually we can easily remove the
ICollection<>from the master-entity and it works as expected without effecting anything for MongoDB. I'll make the related change, and it will probably be included with v9.3.2.Regards.
-
0
Thanks! Bytheway, since this is more like a bug report that an question, can I get my back my questions account?
