-
-
Notifications
You must be signed in to change notification settings - Fork 526
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Persisting collection after wrap(...).assign fails #467
Comments
You disabled cascading, therefore the persist is not propagated to the collection. Working as expected. edit: I see it was not you, but me in the tests :] but the point stays, the property has disabled cascading, and you need |
Sorry, I missed that one, I just tried to reproduce the failure I've seen where I did not set cascade explicitly (which defaults to 'persist' according to docs). But I assign ids directly, not entities. Is this a supported use case? Edit: What I have is:
|
The test is also assigning ids directly. Also the PR does not reproduce anything, the changes before your assert are not flushed, therefore the state stays (there are all 3 tags). |
Try to create reproduction in a separate file, like here: https://github.com/mikro-orm/mikro-orm/blob/master/tests/issues/GH463.test.ts Define the entities there, do not reuse the existing ones so I can clearly see what you are doing and it won't be affected with how the existing entities are defined. |
Thanks, will do that. |
Hmm actually it does not work even with the added |
Ok got it, it is indeed a problem with |
You're too fast, I just finished fixing the test. Thanks. |
I still have this issue, see #469 |
Hmm ok looks like you actually found a bit different problem. Your test was missing |
Ok so the problem is that you are working with the inverse side (the one without FK). ORM by default propagates changes to the owning side so things like this can work, but const b = new B();
b.id = 'b';
b.as.add(a);
// the difference now is that `a.b` will be filled automatically for you, while with assign it was not
console.log(a.b === b); // true |
In my use case I have an upsert with the list of all ids, so I would need to remove the missing ones and add the new ones. Definitely possible, but having this functionality in |
Use
You can use |
Tried this, not as convenient (and confusing when to use what) and also still doesn't work for me. |
Hmm ok the problem is again a bit different, sorry for confusion. You can't work like this with 1:m collections, as they are the inverse side. You need to set the value to the owning side. It works automatically under the hood with I will add validation for this (it is already there for M:N). So to wrap up, you need query builder here, if you do not want to load the owning side entities. ORM always does changeset diffs only on owning sides, and if your owning side is not initialized, there is no changeset. |
That's a bummer as this was one of the main reasons to switch from TypeORM, not needing to double check each modification from which side I have to do these and when I've got it wrong it just fails silently. Would be nice if this would be optional and I could choose to load the owning side under the hood when using |
As said, there is a validation missing. It is there for M:N already. Silent failures are definitely not a valid state.
Well, loading the owner is async operation, so don't expect that to happen automatically by calling synchronous API like |
I imagine it could just be a flag in the collection which would be checked when computing the changeset. Would also need to be checked when loading the primary side of a n:1 or m:n relation. |
I will need to think about this more, maybe we could fire the necessary update query if we see dirty collection on inverse side and we see that the owners are not loaded (I don't think we would have to load the owners this way). Currently the inverse side collection are never marked as dirty. Just for you to understand, the problem is that the changeset that would trigger this is on the owning side (where the m:1 property is), so as long as it is not initialized there is no changeset for that entity, therefore no queries made. |
Previously only initialized items were allowed to be persisted when adding to 1:m collection, due to how propagation works. With this change we now allow having inverse side collections dirty as well, firing single update query for those if we see the items are now initialized. Closes #467
Previously only initialized items were allowed to be persisted when adding to 1:m collection, due to how propagation works. With this change we now allow having inverse side collections dirty as well, firing single update query for those if we see the items are now initialized. Closes #467
Previously only initialized items were allowed to be persisted when adding to 1:m collection, due to how propagation works. With this change we now allow having inverse side collections dirty as well, firing single update query for those if we see the items are now initialized. Closes #467
Previously only initialized items were allowed to be persisted when adding to 1:m collection, due to how propagation works. With this change we now allow having inverse side collections dirty as well, firing single update query for those if we see the items are now initialized. Closes #467
Will be fixed in v4 alpha 9. |
Previously only initialized items were allowed to be persisted when adding to 1:m collection, due to how propagation works. With this change we now allow having inverse side collections dirty as well, firing single update query for those if we see the items are now initialized. Closes #467
Previously only initialized items were allowed to be persisted when adding to 1:m collection, due to how propagation works. With this change we now allow having inverse side collections dirty as well, firing single update query for those if we see the items are now initialized. Closes #467
Hi there, I found this issue while trying to understand why updates within a collection where not being persisted. I think I've read the comments here correctly (and I think I understand them right) in which case my use case should work. I have an entity that has a collection and when I update that entity with one of the collection members also containing updates, those updates should propagate down and all be persisted. This isn't working for me and it could totally be user error (I'm not an expert here). I thought I'd create a super simple repo to reproduce the problem. Would appreciate any guidance but understand this is open source and your likely swamped so no pressure. Big thanks for the library. Example repo - https://github.com/chasevida/mikro-orm-wrap |
The |
Thanks @B4nan for walking me through that, my confusion I think was because it worked in creating the entity that I then wrongly assumed I could update it the same way. Cheers for pointing me in the right direction, I'll go through the EntityAssigner and see if I can make a small tweak for the change with a flag like |
@B4nan ... Continuing what @chasevida asked. How to achieve nested update for entity stored as collection. What other way I can achieve this? As I have a scenario of creating(this works) and updating (which pk are present - currently even passing object with primaryKey id is trying to insert it instead of update it) or deleting(which pk are now no longer present in req payload - orphanRemoval works) nested collections in one of the entity. |
Yes, this ORM always worked like that - presence of a PK does not mean anything. Only way the ORM will issue update query (from flush operation) is when you have the entity already loaded and you mutate its state. Calling
If you want such helper, write it yourself, it's not that hard :] See the |
@B4nan ... I currently implemented the update by finding the collection entity separately using find and doing I also checked the
instead of
|
Nope, we can't change ORM internals because of how assign helper works. Definitely not such integral part like If you want to experiment with something you'd like to propose, it's best to clone the ORM and try what your changed do in the test suite. I can assure you this change would make a lot of tests fail. |
Describe the bug
Ids assigned to a collection via
wrap(...).assign
are not persisted.Stack trace
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I expect that assigning ids to collections works just like assigning an id to a reference with
wrap(...).assign
and would be persisted normally.Additional context
Problem also exists when assigning entities, see PR.
Versions
The text was updated successfully, but these errors were encountered: