Hi, I'm having trouble creating a relation using Designer. Looking at
master, I get a "Processing Request" notification that doesn't go away
and if I force the page to reload, the relation does not exist. Would
someone be able to confirm this before I open a ticket?
Hi,
I'm currently experiencing an issue with hhvm, see
https://travis-ci.org/phpmyadmin/phpmyadmin/builds/32882088
As you can see, all unit tests are ok, except for tests of stristr with
hhvm.
It seems that the hhvm version used on Travis is "HipHop VM 3.2.0".
Does anyone have hhvm (this version or another) please, could run phpunit
on test/libraries/PMA_String_Compare_test.php and give me a feedback?
Thanks,
Hugues
Hi,
I came across the bug #4444 <http://sourceforge.net/p/phpmyadmin/bugs/4444/>
related to export feature for queries.
I'm not sure how exactly this feature is supposed to behave if we are
exporting rows with some but not all columns and also in case we have
aliases and even when we have join queries.
Assume we have tables:
actor (actor_id, first_name, last_name, city_id) with actor_id as primary
key.
address (address_id, adress, city_id, city_id, district, postal_code,
phone) with address_id as primary key and phone have not null unique
constraints.
1. when we select some but not all columns ex,
Select address_id, address from address:
when exported few of the rows, it have create table statement for table
'address' with all the original columns not just these two. and data from
just these two columns in the Insert statements. so here when the same
exported file, we wish to import back will not work as phone have unique
constraint and we are not inserting the phone values.
Also If user is seeing just two of the columns in the table structure at
screen so they might be doing export thinking that it will be exporting the
same structure as on the screen.
2. When we have aliases in column names:
ex: select actor_id, first_name as fname from actor;
So when we export few of the resultant rows, should the create table
statement have a column name first_name or fname ?. As I think of it, It
should be fname, if user have in mind that he is exporting the structure of
the table he is looking at screen.
3. When we have alias in table names:
The name of the table in create statement should be alias name or original
table name?
4. When we have JOIN queries with more than one tables:
ex:
SELECT * FROM (SELECT actor_id FROM actor as e INNER JOIN address as g on
e.actor_id = g.city_id) as t1
Currently if we try to export some rows from the above query, it export
nothing it goes on edit sql screen.
Please share your thoughts.
Thanks and Regards
- Smita
Hi Edward,
Is there any provision for refreshing the Console at the bottom when user
selects a particular database from the Navi panel; similar to the option to
refresh the Navi panel?
I need this so that we can show the 'Bookmarks' link when the phpMyAdmin
configuration has been set up dynamically (without changing config.inc.php).
--
Ashutosh Dhundhara
Robert Scheck a écrit :
> Hello phpMyAdmin developers,
>
> how hard is the requirement for MySQL >= 5.5 in phpMyAdmin? Actually, I am
> the package maintainer of phpMyAdmin in Fedora and EPEL. EPEL is an add-on
> repository for Red Hat Enterprise Linux and CentOS (and other derivates).
>
> However, Red Hat Enterprise Linux 6 is shipping only MySQL 5.1 and Red Hat
> Enterprise Linux 5 is only shipping MySQL 5.0. And unfortunately since the
> phpMyAdmin 4.2.3 release you are enforcing MySQL >= 5.5 as requirement -
> which breaks both of them.
>
> We could stay with phpMyAdmin 4.0.x for both, but 4.0.x goes EOL already in
> less than 6 months - quite early given that RHEL 6 is supported till 2020
> (and RHEL 5 until end of March 2017). I do not expect that you support old
> releases same long like that. However it would be really helpful can give
> some details why the requirement is enforced and what could break with an
> older version (some specific features, mostly everything, everything?) of
> MySQL.
>
> Thank you very much for your time already and hope to hear some details :)
>
>
> Greetings,
> Robert
Hi Robert,
today we have extended security support of phpMyAdmin 4.0; the new date
is Jan 1, 2017.
--
Marc Delisle (phpMyAdmin)