I would probably add a to-do of sorts to improve on my method, I just
implemented it in that way for completion speed and not needing to affect
surrounding code. Sending a query to MySQL which just returns a static list
is probably too hacky to be considered production worthy. Some similar code
would probably be best placed in the higher levels of the navigation tree
builder which does not even attempt to call this function and instead
return the array at that point. I hope that time will permit me to optimize
my own hacks but it shouldn't be something to be relied on.
Thank you.
On Thu, Nov 21, 2013 at 10:12 AM, Marc Delisle <marc(a)infomarc.info> wrote:
Martyn Dale a écrit :
Hi Marc,
4.1.0 is no worse in this regard than 4.0.x, however given that the
performance issues appeared to be the primary reason for the dropping of
5.1 in 4.1 (at least that was the implications from postings in the
discussions of the show databases command and disableIS issues), I
thought
it important to express that, not just so the
underlying issue can be
resolved for MySQL versions 5.5 and above, but also because a number of
distros still ship MySQL 5.1 as its default version, as do multiple
shared
hosting providers and that keeping 5.1 support
would probably benefit a
reasonable percentage of your userbase.
Unfortunately due to time constraints, offering a fully working solution
is
not something I am able to do at present, however
I can provide my
(admittedly horrifically hacky) solution that solves the most severe
issue
experienced.
I added code to getData (libraries/navigation/Nodes/Node.class.php) which
is provided at the close of this message. The purpose of this was to
simply
return a query object that contained the static
information based on the
only_db contents. This way, the related node building functions did not
also need to be edited. For the start of a more complete solution, I
would
add a check in there to make sure only_db is
actually set before building
it, otherwise having it fall back over to the non database code, as the
code provided will fail if only_db is not set.
The only downside to this base approach is that if an only_db database
does
not exist, it will still display on the
navigation (whereas currently it
would not), however its children of course wont as they still use the
classic checks. It might however be an opportunity to display that fact,
so
users who use only_db are informed they have non
existent databases in
their list.
Following is probably some of the most horrible code to hit the mailing
list, but hopefully it gives someone who is more familiar with the PMA
codebase an idea. I shall also keep an eye on the mailing list in case I
get the time to offer something a little more substantial.
Thanks Martyn,
I have committed this code in your name:
https://github.com/phpmyadmin/phpmyadmin/commit/30d9af4789fafdf766ea2c3eb0e…
adding a check for the existence of only_db as you suggested. This way
we can all test the behavior of your suggestion.
About the minimum MySQL version supported (5.5), as discussed on this
list, "Considering that MySQL 5.5 has reached the "Generally Available"
status on 2010-12-03 with version 5.5.8" we now mention that this is the
minimum version supported. This MySQL was released three years ago.
Note that the code does not block your using phpMyAdmin 4.1.x with MySQL
5.1, but it's not supported (meaning no tests, no fixes for
5.1-specific issues, etc).
--
Marc Delisle
http://infomarc.info
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up
now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.cl…
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel