Hi Isomorphic,
I had a problem here now where there were too many rows being displayed.
Reason was a coding error, but perhaps the framework could warn here or even better refuse requests execution (as an option, if there is something that feature would break from your point of view).
The issue was that I was generating criteria for a field, that was in the DB as expected, but missing in the .ds.xml (our mistake).
The framework here silently defaults to WHERE (1=1) / ignoring the criteria.
Perhaps you could either issue a warning here in the log or even better not execute the SQL at all and return an error.
I think that you should also be able to log something client side if this happens and the "wrong" criteria was added clientside, as the DataSource is also loaded in the client normally (always?) if you want to use it from there. My focus is on the serverside though, as this would handle both cases.
Does this suggestion make sense to you?
Thank you & Best regards
Blama
I had a problem here now where there were too many rows being displayed.
Reason was a coding error, but perhaps the framework could warn here or even better refuse requests execution (as an option, if there is something that feature would break from your point of view).
The issue was that I was generating criteria for a field, that was in the DB as expected, but missing in the .ds.xml (our mistake).
The framework here silently defaults to WHERE (1=1) / ignoring the criteria.
Perhaps you could either issue a warning here in the log or even better not execute the SQL at all and return an error.
I think that you should also be able to log something client side if this happens and the "wrong" criteria was added clientside, as the DataSource is also loaded in the client normally (always?) if you want to use it from there. My focus is on the serverside though, as this would handle both cases.
Does this suggestion make sense to you?
Thank you & Best regards
Blama
Comment