-
Notifications
You must be signed in to change notification settings - Fork 46
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
Assert data are unchanged during save #1053
Comments
it would be great if you can add a simple model code |
Just save a value to any model entity which is already saved, so conceptually:
(sure this is not realistic - but can well be that code will save a newly calculated field which is identical to a stored value. And that is perfectly fine, no need for Exception. |
@mvorisek Sorry for the abbreviated example - I tried to reproduce myself. The error was there when I did the following:
|
Thanks for the repro code. I will repro on my side and double check the exception. Aggregated fields should never be allowed to set in the first place and maybe we can throw an exception earlier.
this exception is "last resort" - it prevented you from doiing something nasty correctly |
No, in this example I do not set an aggregate field: I create aggregate fields (see they are notes _pos at the end) to calculate the sum of the positions. This sum then is stored into a simple field in the orderdoc. This works always fine, only if you save the identical sum over the already saved one gives you that error. The error says that 1 expected row to be affected but 0 rows changed which is correct - but also not a problem. |
I still do not understand the repro steps fully. @mkrecek234 Please post here a simple model /w one aggregate field and simple use of it, which throws the exception. |
@mvorisek I haven't yet achieved to write nice repro code but I analysed it further. The circumstance leading to this error is:
What does this teach me: The framework once again became even better - also these very detailed issues will be highlighted properly. So, thank you @mvorisek |
P.S. This happens also if your database is configured NOT to allow NULL values for a specific field, this field has stored a So to summarize for other users: Whenever there is a mismatch in field type configuration between the database and Atk4/Data model field setup, you might likely encounter the error above. |
Yes, a lot of work is done to detect such data mismatches. I am reopening, as when we read the data after save (insert/update), we can even assert all values are stable, ie. not changed by the DB like rounding or null->empty. |
@mvorisek Let me explain how to reproduce:
Lets's assume there is a record with id=1 which has the following stored values: Amount=13.02 and intvalue=0 Now you have a model which is defined in this way:
(You see the mismatch to the DB definition: 4 digit precision vs. 2, and nullable false vs. true If on this you perform the following save functions:
or you do Why? Because correctly Atk4 sees that there changed values, so updateRaw command is executed. However, there are only 0 affected rows wheres 1 expected, because the corrected value by the database (round(amount,2) and also the null value transformed to 0) are the same as the stored value and would not mean an updated row. So this is unrelated to the aggregate function. Just bad setup by me with mismatching field definitions 😀 And in my setup only with the recent changes in Atk4/Data the error was correctly detected. So thumbs up to those improvements incorporated👍 |
The repro steps/issue is clear since your previous comment. The |
Use case: You have code which updates the total sum of an order. Now the customer adds an order position with price = 0.
You don't want to deal with it but just save the new total (which is identical to the old total).
Steps to reproduce:
You will get this error in recent develop branch:
Atk4\Data\Exception: Update failed, exactly 1 row was expected to be affected
I don't think this is an exception - testing for changes is done in save command - if not change happens because re-save of prior set values, then it is not an Exception. This behaviour was added with the recent changes in Atk4/Data
The text was updated successfully, but these errors were encountered: