M2M without on_conflict

[Forceres]

I think that on_conflict part in add_m2m would be very useful for avoiding duplicates in m2m, why it isn't supported yet?

[sinisaos]

@Forceres There was a PR for it, but it never took off. Maybe @dantownsend has a better way to solve that problem. As you can see in that PR, it's just a few lines of code (with combination of unique constraints in joining_table) that would be useful to prevent duplicate entries in M2M.

[Forceres]

@Forceres There was a PR for it, but it never took off. Maybe @dantownsend has a better way to solve that problem. As you can see in that PR, it's just a few lines of code (with combination of unique constraints in joining_table) that would be useful to prevent duplicate entries in M2M.

A lot of vital PRs were not merged. What a pity!

[sam2x]

I second this requirement.

@dantownsend Is there any reason this PR is not validated ? Could you please share any strategy on sorting/accepting PR
?
You provided an answer on the PR without merging it, was it a mistake ?

This is a big win PR as it's small code, fast to review/confirm it doesnt introduce no edge-case, and the benefit are majors:

• Semantic Ambiguity: Duplicate entries make the meaning of the M2M table unclear.
• Data Integrity Issues: Duplicates complicate data integrity.
• Query Count Complexity: If I rely on this to retrieve unique relationships or counts, it become more complex as you need to account for and filter out duplicates.
• Performance Degradation: Unnecessary duplicate data increases storage space and can potentially slow down queries.
• Violates Relational principal: Relational databases are designed for efficient representation of relationships.

Therefore having duplicates doesnt serve well the quality of this lib that has been quoted as "production-ready" on some thread...
To tackle this, and providing you support, please indicate if you need help on qualifying/sorting making priority triage on PR/features that are worth (To me this is one of them). Many can help (including me).

Best regards,

[Forceres]

I second this requirement.

@dantownsend Is there any reason this PR is not validated ? Could you please share any strategy on sorting/accepting PR ? You provided an answer on the PR without merging it, was it a mistake ?

This is a big win PR as it's small code, fast to review/confirm it doesnt introduce no edge-case, and the benefit are majors:

* **Semantic Ambiguity**: Duplicate entries make the meaning of the M2M table unclear.

* **Data Integrity Issues**: Duplicates complicate data integrity.

* **Query Count Complexity**: If I rely on this to retrieve unique relationships or counts, it become more complex as you need to account for and filter out duplicates.

* **Performance Degradation**: Unnecessary duplicate data increases storage space and can potentially slow down queries.

* **Violates Relational principal**: Relational databases are designed for efficient representation of relationships.

Therefore having duplicates doesnt serve well the quality of this lib that has been quoted as "production-ready" on some thread... To tackle this, and providing you support, please indicate if you need help on qualifying/sorting making priority triage on PR/features that are worth (To me this is one of them). Many can help (including me).

Best regards,

Many old issues that must be in production-ready ORM are not resolved yet (for instance, reversed relationships). I was forced to move to SQLAlchemy.