I played around a bit with this really nice feature, but noticed a small
bug: When using 'display all tables with same width' the
connections on the right side of the boxes are actually behind the
Logged In: YES
Still present in phpMyAdmin-2.4.0-rc2.
Logged In: YES
please post a dump of your table structure. I cannot verify this
using normal-length tables.
with and without same width table (example)
I created a "screenshot" which should make clear what I mean.
Some details I forgot to mention:
I used phpMyAdmin-2.4.0 for this
"screenshot". The upper part is with "display all tables with same width"
disabled, while the lower part was taken with enabled option.
Logged In: YES
I am having this problem as well (2.4.0).
I was able to debug the problem, but unable to come up with
a nice fix.
The problem is with the PMA_RT_Relation class. When this
class is initialized, both the master and foreign tables are
passed in. At this point, the
PMA_RT_Relation::PMA_RT_Relation_getXy() method determines
the X,Y co-ordinates for the line.
Unfortunately, it uses the current $table->width for both
tables. These widths correspond to the actual table widths,
and not the final "same widths". This is because the "same
width" isn't determined until the tables are actually drawn,
and that occurs well after the PMA_RT_Relation objects are
Thus, 2 problems:
#1) In PMA_RT::PMA_RT(), the relations are drawn before the
tables. This needs to be reversed. This is very easy to do,
and quickly shows where the arrows are pointing, since they
now appear on top of the table.
#2) We need to defer initializing the XY co-ords of the
PMA_RT_Relation until after we know the final width of the
tables. Three solutions suggest themselves to me:
a) Have the PMA_RT_Relation table hold a reference to the
PMA_RT_Table objects, and determine the $table->width at the
last possible moment (ie: at the time of drawing, instead of
b) At the time of drawing, pass in the same_size variables,
and get the drawing function to make any adjustments
necessary (this would require the class to store the
previous $table->width and adjust based on that)
c) Defer creating the relation objects at all until after
the tables have been drawn.
I tried implementing (c) with my meager PHP skills. It
seemed easy enough, but it doesn't appear that the
PMA_RT_Table objects are ever updated with their final
width...it is merely a copy of those tables that gets
modified. I gave up before digging too deeply.
Hope this helps. If any developer wants a copy of my
databases in order to see this problem in action, I'm happy
to send them a full .zip.
thanks for your valuable input. I also had a look at the
current structure and you are absolutely right with your
statements. The whole code really needs a rewrite to
implement the correct evaluation of the widths. I tried some
workarounds on the code, but I'm not satisfied with them
because they loop through some functions more than once.
Of course that shouldn't be, so I have to postpone that fix
until there's more time to evaluate/rewrite, or maybe the
original creator of this function is still into the code and
can do the necessary rebuilds in a blink of an eye. ;-)
I've created a fix. A little kludgy, but not bad: basically
I pass in the "same_width" and "table_width" values into the
Relations class. Only about 8 lines of code all in.
I made the changes against the latest copy I could find
(part of the March 31 2003, 06:36:26 PM (GMT) snapshot).
What is the best way for me to submit them....I'm an open
source rookie. (Using windows, though I have a linux box
available to me as well)
that's great. Thanks for your effort, I just wanted to start
taking more time on that issue.
I'd be glad if you attach the fix to this page. I will then try to
integrate the fix.
The new version of the file is available here:
I'm sorry but your fix does not seem to fix this problem for
me. I'm afraid that we still have the problem, that the 'real'
tablewidth is calculated at the end of all 'loops' when the
arrow positions are already placed. Shoving those variables
into the functions does therefore not really help.
I'll try to put together a patch which calculates the
arrowheads after the main calculations. This will take some
Strange, it works for me. I've posted samples here:
In each case, the only change I made was to copy "my"
pdf_schema file over the original one, or vice versa.
you are right, it works with your layout. Mine is completely
different. I'll try to create a dump from my structure and
do some further evaluations the next day. I'll post my
Thanks for your effort, in any way. Your pdfs help a lot on
solving this 'case'. :-)
Getting sick of this yet? :)
As is turns out, it didn't 100% work for me either. However
by using my original idea of creating the Relations objects
at the very end, it seems much better.
More notes here, along with more sample pdf's:
it's you who does the major work, so why should I get sick? ;)
Anyways, your latest patch works for me. One thing I notice
is that the relational lines get drawn above the table. I
personally like that better than having the lines below the
Is there anyone here who dislikes the idea of overlaying lines?
Though, this only shows up in certain layouts of your tables...
I will include your patch, if there are no objections the next 1-
2 days to this thread. Thanks for your work...
Logged In: YES
Garvin and Doug,
the fix works here for my test tables, so +1 for including
Implemented to CVS.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.