|
Bug Notes |
|
|
hbernard
|
|
2004-04-18 15:21
|
|
Sample :
On the server side, you have a field which is unique and indexed at the MySQL database level.
On the client side, user want to be able to specify there one key-value for this field.
You can't do automatic filling of the key value.
You can't put in a dropdown all the available key values.
(because it is not usable, and because this would be too slow)
So you use a text entry.
But then, user may want to use an already used key-value.
(they can't see the whole records for security reasons,
or/and they can't read all the values in list mode for checking if the one they want is available)
This cause logically MySQL to return an error, and this is very ugly from the client side.
Feature request above aims at being to handle this by hand, and print a more helpful advice !. |
|
|
|
|
Yes, nice addition.
But I believe we do not want to correct things in this trigger and let phpMyEdit to do particular SQL operation once again. :-) |
|
|
|
hbernard
|
|
2004-04-18 18:40
|
|
Yes, of course :)
This is just for smarter display.
Only thing that I can imagine we can do (apart displaying) is to go back to the add mode, for example, to let user change the faulting field |
|
|
|
|
displaying bad input could be done similarly to php input validation in example (bug #228).
however, i would put this into do_*_record for two reasons:
- some triggers are already there
- $newvals array is already present for displaying bad input
and use ['triggers']['insert']['sql-error'] just for consistency |
|
|
|
hbernard
|
|
2004-04-18 20:46
|
|
I disagree.
I want it to be simple, not to add many lines in pme.
0. what do you mean with "similarly to php input validation in example (bug #228)" ? I don't understand.
1. About where to put the code :
A good thing with PME is that there is ONE func which is doing all the querys.
Why wanting to bloat the class with lines in multiples func. Isn't that what you are trying to do with 'hidden var' bug and $this->row in 'output control' bug ???
And,
About the API :
I planned to implement
['triggers']['sql-error']['all']
and
['triggers']['sql-error'][1209]
Where 1209 is a specific error code.
This is consistent in another way : type and subtype of trigger.
Nepto has to make a decision. |
|
|
|
|
0. just to display bad input. you need $newvals array to do this. the only way i found to display bad input is though 'default' (the record is not in the database).
1.a trigger would echo a custom error message at the top of the page (the same place as current error messages are echoed) ?
(at first i thought more triggers can be active at the same time, and putting error messages in the 'help' area of a field, stupid me)
2. api: '1209' would act if error #1209 is found, 'all' is 'all-others' ? (if error #205 and no '205' trigger is found, 'all' is used, if '205' is found, '205' is used)
2.5. then this api is consistent.
2.6. ['1209'] or [1209] or both (prefferably) ?
3. this would display also errors in LFV.. modes, where there is no user input (so there is none to be displayed) |
|
|
|
hbernard
|
|
2004-04-20 18:31
|
|
0. I'm really sorry, I still don't understand. I have to read your trigger.
<UPDATE> Ah, yes, I see the issue. Maybe you are right to want it in do_*_record. Will think about it</UPDATE>
1. YES, you got it.
2. YES, that's it.
2.6. I suggest '#1209' to avoid confusing users and have a simpler patch.
3. yes, this would display also error in LFV modes (to be sharp : display happen during do_*_record (so in A/C/D mode) but is immediately followed by the L or F mode)
This is what current MySQL error message are doing, so I don't understand your point.
edited on: 2004-04-20 18:46 |
|