[jpr]

Thanks for these explanation....

For allowMultiUpdate, the system allows blank criteria (affecting all rows), because that can be what's intended. It also makes no attempt to verify that the values in the criteria are correct in any way, because again the system has no way of knowing what you intend.
-> if criteria is "where user=5", the system can sure know that field "user" exists or not in datasource. He can know something is wrong, even if not knowing what I fully intend

Therefore when using allowMultiUpdate, if you intend the criteria to be constrained in some way, you *must* write code to check it - there is no possible way the framework could do it for you. And if you write appropriate code to make sure expected criteria values are present, then your code will also catch a typo in a criteria field name.
-> I found a way to check if the criteriaColumnName exists in dataSource:
dataSource.getFieldNames().contains("user")
-> why is it so complicated for you to do this in the framework? And to return an appropriate exception instead of replacing my "where user=5" with a " where 1=1"?

Best regards

[Isomorphic]

Please re-read previous post. The conclusion was that while such a check could be added, it would be useless, because it would be redundant with your own checks.

[Blama]

Hi Isomorphic,

I also agree with jpr. IMHO it is not only for Primary Key fields, but in general for detecting mismatching fields in client/server or even servercode/.ds.xml communication. For me, this is not about multiUpdates, but about preventing application bugs created by developer-typos.
This also affects data-updates and fetch-criteria.
For me, most of the calls from the client do not rely on extra record data, where there is no DataSource field in the .ds.xml. For those calls, having the guarantee, that all data sent is expected and will be processed is valuable.
Imagine BuiltInDS and for some reason the field name of employees.EmployeeStatus is changed to employees.Status. Now of course one should and will do this change in the Java code everywhere, but what if I miss a line?

Here this feature would help. And if not needed/wanted, one could always disable it, as described in #9.

Best regards
Blama

[Isomorphic]

Blama, as we covered in #8, the system routinely ignores "extra" data in criteria/values, and your application relies on this - you just may not be aware.

If you would like to understand how often this happens, capture a snippet of your application's logs from live usage. You'll see that it is very common. "Extra" values on records come from:

• temporary client-only form fields
• behavioral flags that can be set on records (see all of the listGrid.record* properties for example)
• state kept on records by application code
• metadata kept on records by SmartClient components (selection markers, tree structure, etc)

Note also that it would be easy for you to write your own mechanism for checking for extra data, and you could, perhaps, over time, develop a long list of cases that definitely aren't typos and so can be silently ignored. However, once you've analyzed the frequency with which extra fields appear, we think you'll agree that this isn't a productive path.

Either way, please don't follow up asking for a "strict mode" again until you've done an actual analysis of how often you are relying upon extra fields being dropped.

[jpr]

Hi Isomorphic,
as I could see, you're still confusing with the request here...

If you would like to understand how often this happens, capture a snippet of your application's logs from live usage. You'll see that it is very common. "Extra" values on records come from:

• temporary client-only form fields -> is this criteria fields?
• behavioral flags that can be set on records (see all of the listGrid.record* properties for example) -> is this criteria fields?
• state kept on records by application code -> is this criteria fields?
• metadata kept on records by SmartClient components (selection markers, tree structure, etc) -> is this criteria fields?

Note also that it would be easy for you to write your own mechanism for checking for extra data, and you could, perhaps, over time, develop a long list of cases that definitely aren't typos and so can be silently ignored. However, once you've analyzed the frequency with which extra fields appear, we think you'll agree that this isn't a productive path.
-> I did such analysis, and there was only one time when I got a extra criteria field: when I did a typo erro, which results in a really bad query (that's why I love my backups ;))

Either way, please don't follow up asking for a "strict mode" again until you've done an actual analysis of how often you are relying upon extra fields being dropped.
-> strict mode is too complex. I would prefer a "CheckCriteriaFieldTypo". I mean during the testing phase of this improvment

JP

[Isomorphic]

jpr, if you're going to continue to post, please read more carefully. You've responded to a discussion about extra values (not criteria) talking about criteria. As far as criteria, you have not responded to the explanation of why it would be useless (#15).