6 Feb
2004
6 Feb
'04
1:03 a.m.
Hi,
since the addition of the multi-row delete (and edit) feature,
we have a nested forms situation when PMA_linkOrButton() decides
that (probably due to a missing primary key), a generated link
would be too long, and creates a mini form instead.
I see 2 solutions:
1. When called from display_tbl.lib or display_tbl_links.lib,
pass an additional parameter to PMA_linkOrButton(), which would
tell the function to avoid creating a button via a form if the URL
length is too big. So the only way to edit or delete this row
would be by ticking and use "With selected".
2. Before starting the form that calls tbl_row_delete, try to
detect if the rows data is going to trigger the generation of
a button, and if so, do not offer the multi- feature. The absence
of no unique keys would be a case.
Comments?
Marc
6 Feb
6 Feb
7:08 a.m.
Hi Marc!
since the addition of the multi-row delete (and edit)
feature,
we have a nested forms situation when PMA_linkOrButton() decides
that (probably due to a missing primary key), a generated link
would be too long, and creates a mini form instead.
I just read that item, and I was shocked. I almost completely forgot
about this. :-)
I see a general problem with the form method. When we place them all
in a huge loop it will create huge amounts of POST data, which can
lead to timeouts or POST-size limits when dealing with blob-fields
without primary keys.
1. When called from display_tbl.lib or
display_tbl_links.lib,
pass an additional parameter to PMA_linkOrButton(), which would
tell the function to avoid creating a button via a form if the URL
length is too big. So the only way to edit or delete this row
would be by ticking and use "With selected".
As an enhancement to that solution we could edit/delete a single row,
if we move the tag each button per row with a unique id. The
evaluation of tbl_row_delete will then take care that the row on which
the button was pressed will be seen as marked.
With JavaScript, the button could just untoggle all rows and only
toggle the one of the clicked row and submit it then to
tbl_row_delete. This would workaround having to click on "With
selected".
2. Before starting the form that calls tbl_row_delete,
try to
detect if the rows data is going to trigger the generation of
a button, and if so, do not offer the multi- feature. The absence
of no unique keys would be a case.
Regarding the note above I see too many possible problems and I think
it would be best to disable multi-row for that cases. Additionally I
think a visible (but not disturbing) message should be generated on
screen which tells the user that he SHOULD put a primary key on his
column.
$0.02,
Garvin.
7:52 a.m.
Hi Marc, Garvin & list,
Garvin Hicking wrote:
It's not only that: depending on how many fields the user defined for his
table, the form itself could be too huge if many records are selected.
Sounds like a task to work on for 2.5.7 ;-)
What about displaying the forms page-wise?
The user would get the form for the first record he selected. In this form,
we would include some hidden input fields that store the keys of those
records that haven't been edited yet.
When the user submits the form for the first record, we would perform the
UPDATE query and
- display the first form again, if the UPDATE query fails, or
- display the form for the next record otherwise
and so on. This way, we would get around large HTML forms and POST data.
I also wonder about another optimization:
If the user has defined a unique key over NOT NULL coloumns only, we should
be able to use this one instead of the primary key. Of course, this only
makes sense, if the unique key is smaller than the primary one.
since the addition of the multi-row delete (and
edit)
feature, we have a nested forms situation when
PMA_linkOrButton() decides that (probably due to a missing
primary key), a generated link would be too long, and creates
a mini form instead.
I just read that item, and I was shocked. I almost completely
forgot about this. :-)
I see a general problem with the form method. When we place
them all in a huge loop it will create huge amounts of POST
data, which can lead to timeouts or POST-size limits when
dealing with blob-fields without primary keys.
Regarding the note above I see too many possible problems and
I think it would be best to disable multi-row for that cases.
+1 from my side.
Additionally I think a visible (but not disturbing)
message
should be generated on screen which tells the user that he
SHOULD put a primary key on his column.
I fully agree.
Perhaps we should also warn the user if he has created a new table without
any primary or unique keys.
Anyway, I suggest to add a small note about this issue to our README and /
or release notes for 2.5.6.
Regards,
--
Alexander M. Turek
<rabus(a)users.sourceforge.net>
_ __ __ _ _ _
_ __ | |__ _ __ | \/ |_ _ / \ __| |_ __ ___ (_)_ __
| '_ \| '_ \| '_ \| |\/| | | | | / _ \ / _` | '_ ` _ \| | '_ \
| |_) | | | | |_) | | | | |_| |/ ___ \ (_| | | | | | | | | | |
| .__/|_| |_| .__/|_| |_|\__, /_/ \_\__,_|_| |_| |_|_|_| |_|
|_| |_| |___/
<http://www.phpmyadmin.net>
7476
days inactive
7476
days old
2 comments
3 participants
participants (3)
-
Alexander M. Turek -
Garvin Hicking -
Marc Delisle