New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

export to SQL format not available for tables #14775

Closed
thelounge-zz opened this Issue Dec 11, 2018 · 25 comments

Comments

Projects
None yet
8 participants
@thelounge-zz
Copy link

thelounge-zz commented Dec 11, 2018

4.8.4: database can be exported as sql, for tables it defaults to "CodeGen"

yes, maybe it's because of my rpmbuild deletes a large part of folders and files because in the past few years phpMyAdmin became a horrible bloat, but there is no rational reason differ in that part
phpMyAdmin: 4.8.4

@ibennetch

This comment has been minimized.

Copy link
Member

ibennetch commented Dec 12, 2018

I confirmed this with 4.8.4, but not with the current master.

SQL isn't even available as a table-level export option, but works as expected for database- and system-level exports.

@ibennetch

This comment has been minimized.

Copy link
Member

ibennetch commented Dec 12, 2018

Git bisect tells me that c1cdaac is the first bad commit, @mauriciofauth could you take a look?

@ibennetch ibennetch added the bug label Dec 12, 2018

@lotharsm

This comment has been minimized.

Copy link

lotharsm commented Dec 14, 2018

I can confirm this for 4.8.4, haven't tried the current master since the installation in question is running in a production environment.

@ibennetch ibennetch added this to the 4.8.4.1 milestone Dec 14, 2018

@ibennetch

This comment has been minimized.

Copy link
Member

ibennetch commented Dec 15, 2018

If we can fix this in the next few days, I'd be interested in releasing 4.8.4.1 along with #14782.

@ibennetch ibennetch changed the title export to sql-format not available for tables export to SQL format not available for tables Dec 17, 2018

@bs-thomas

This comment has been minimized.

Copy link

bs-thomas commented Dec 19, 2018

Wow, what an issue... Looking forward for the fix soon! Thank you so much guys!

@williamdes

This comment has been minimized.

Copy link
Member

williamdes commented Dec 19, 2018

git bisect found that c1cdaac is the first bad commit.

@williamdes williamdes self-assigned this Dec 19, 2018

@thelounge-zz

This comment has been minimized.

Copy link
Author

thelounge-zz commented Dec 19, 2018

can someone please fix that tragedy because it's simply impossible in that overengineered codebase to even guess where the values for the select are coming from and when you are at it stop leaking phyiscal temp-dir as full-qualified path in the import screen and make all that "hey place files on the server and select them in phpmyadmin" stuff OPTIN for the sake of security

@idonda

This comment has been minimized.

Copy link

idonda commented Dec 19, 2018

@thelounge-zz can you temporarily downgrade to 4.8.3?

@williamdes

This comment has been minimized.

Copy link
Member

williamdes commented Dec 19, 2018

@thelounge-zz I am fixing this issue in minutes ;)

williamdes added a commit that referenced this issue Dec 19, 2018

Add ChangeLog entry for #14775
Signed-off-by: William Desportes <williamdes@wdes.fr>
@thelounge-zz

This comment has been minimized.

Copy link
Author

thelounge-zz commented Dec 19, 2018

how can 9511484 which just copies a GET value to a GLOBALS (shrug) fix the content of a select-field?

@williamdes

This comment has been minimized.

Copy link
Member

williamdes commented Dec 19, 2018

@thelounge-zz You can confirm that 9511484 fixes the issue ?

@williamdes williamdes added the has-pr label Dec 19, 2018

@thelounge-zz

This comment has been minimized.

Copy link
Author

thelounge-zz commented Dec 19, 2018

[root@srv-rhsoft:/downloads]$ cat Export.php > /usr/share/phpMyAdmin/libraries/classes/Display/Export.php

indeed - it's displayed again and even working - i honestly don't want to understand the codebase behind which seems to work out of a miracle

@idonda

This comment has been minimized.

Copy link

idonda commented Dec 19, 2018

@williamdes it does fix the problem for me.

@wzltr0n

This comment has been minimized.

Copy link

wzltr0n commented Dec 27, 2018

Good news... if I select the db, then checkbox the table(s), exporting under "with selected" I get the SQL option :)

I can also export the full database. Glad there are workarounds for this otherwise debilitating issue.

@pxao02

This comment has been minimized.

Copy link

pxao02 commented Jan 16, 2019

Any clue when version 4.8.4.1 gets released? I can't use the master branch on production servers, and more and more clients are noticing the missing export. I could point them to the workaround for a while but it's getting a bit tiresome now :)

@thelounge-zz

This comment has been minimized.

Copy link
Author

thelounge-zz commented Jan 16, 2019

@pxao02 while i also don't get why there is no bugfix release you can simply replace that one single file and are done for now, and yes i normally build phpMyAdmin rpm packages but that don't mean you can't overwrite a single file in the meantime

#14775 (comment)

@pxao02

This comment has been minimized.

Copy link

pxao02 commented Jan 16, 2019

Good point @thelounge-zz I might consider doing this if it doesn't get released any soon.

@ibennetch

This comment has been minimized.

Copy link
Member

ibennetch commented Jan 16, 2019

@pxao02 and @thelounge-zz My plan was to release 4.8.4.1 as a quick fix for the several regressions caused with 4.8.4 (which were all related to a security change we made), but it seemed like #14800 was also related and I was holding the release for a fix for that issue.

Meanwhile, the continued development cycle meant that 4.8.5 continued to get regular bugfixes and we're coming up on the time I intended to release that next version, which I tentatively planned for a release early next week. Releasing that and the concern over not having #14800 fixed yet kind of created conflicting goals now, where I have to balance releasing a fix for the export issue that contains a known issue with the process list, or if I wait for 4.8.5, or do I hold 4.8.4.1 until the process list issue is fixed. Honestly, I expected a quick fix for the process list issue just like the sql export issue was quickly fixed, and that hasn't happened...perhaps I decided wrongly to wait on the release and now I think I should have released 4.8.4.1 sooner, but it wasn't until a few days ago that the whole big picture view of the timeline became clear.

So I may be able to release 4.8.5 a bit earlier than planned, in order to get this and a few other fixes out.

All that to say basically that I was waiting for a fix that hasn't happened, I think that was a mistake, but now we'll probably soon see a release of version 4.8.5 instead of 4.8.4.1.

Of course, we regret the inconveniences this has caused and are grateful for your patience and understanding.

@idonda

This comment has been minimized.

Copy link

idonda commented Jan 16, 2019

@ibennetch thank you. Interesting to know what is going on behind the scenes. keep up the good work

@thelounge-zz

This comment has been minimized.

Copy link
Author

thelounge-zz commented Jan 16, 2019

don't get me wrong but "where I have to balance releasing a fix for the export issue that contains a known issue with the process list" is pure nonsense! currenmtly you only have a old insecure or a new version available with obviously more than one issue

so how could it be more bad fix the low haning fruits and make a point release still containing the other bugs than only have a completly buggy version available?

@pxao02

This comment has been minimized.

Copy link

pxao02 commented Jan 16, 2019

Thank you @ibennetch !
For me personally it will not make a difference whether you release 4.8.4.1 or 4.8.5. What matters most is that either one of them will be released soon enough to fix the SQL export, which is causing us the most trouble with our clients :)

@ibennetch

This comment has been minimized.

Copy link
Member

ibennetch commented Jan 16, 2019

@thelounge-zz I'm sorry you feel that way, but when the security flaw was fixed, a side effect was that a few places where requests were being passed between code blocks got missed and there were several similar bugs as a result of that fix. Would you have preferred for me to release 4.8.4.1 for the Text_Plain_Sql error, then three days later release 4.8.4.2 for the two-factor QR code, and two days after that release 4.8.4.3 for this SQL export issue? Some people do prefer a rapid release cycle, but most of the feedback we've gotten indicates that people would prefer we group fixes like these to make one release. Since several of the regressions were directly related to the one code change, it seemed to make sense to hold off on a release until all of the related problems were fixed at once.

Unfortunately, it turns out that the one that seemed related (and may still be) took longer to diagnose than expected. There's a skill to balancing "I need a few days to figure this out and fix it" against realizing "This is going to take longer than I expected," and I messed up.

I think your point about fixing the low hanging fruits is the exact detail that caused 4.8.4.1 to slip by a week or two here; I thought the final issue was a low hanging fruit that was closely related, so I was chasing that to include as part of the release.

@thelounge-zz

This comment has been minimized.

Copy link
Author

thelounge-zz commented Jan 16, 2019

the answer to "Would you have preferred for me to release 4.8.4.1 for the Text_Plain_Sql error, then three days later release 4.8.4.2 for the two-factor QR code, and two days after that release 4.8.4.3 for this SQL export issue" is CLEARLY YES

in doubt i prefer every two days throw a tarball into /rpmbuild/SOURCES/ and fire up rpmbuild because it's cheaper than a single phone call why some crap don't work now and how to solve it for the user

"but most of the feedback we've gotten indicates that people would prefer we group fixes like these to make one release" - these people are morons! nobody is forcing them to deploy 4.8.4.1, 4.8.4.2, 4.8.4.3 on the day they are released, the can just ignore them if they think all is running fine enough

@ibennetch

This comment has been minimized.

Copy link
Member

ibennetch commented Jan 16, 2019

I want you to know that we take your feedback seriously and consider these things when evaluating our long-term plans. Thanks for sharing your views on this.

@thelounge-zz

This comment has been minimized.

Copy link
Author

thelounge-zz commented Jan 16, 2019

and small point releases have the advantage in case they contain a regression by themself that it beomces qucikly clear from where they are coming besides when 4.8.4.1, 4.8.4.2, 4.8.4.3 all have several bugs you can chose which of them affect you most

as example i could not care less about "process list issue" because i owuldn't miss the whole feature at all like for a lot of stuff phpMyAdmin was bloated with over the years and features like "chose a file from the server for import" leaking a phyiscal path to the user are making me terrible angry to begin with

honestly i want my old phpMyAdmin where you had a frameset and no ajax at all back with just security fixes instead have "rm -rf" and a patched css full of "display:none" the biggest part of my rpmbuild specfile

@ibennetch ibennetch modified the milestones: 4.8.4.1, 4.8.5 Jan 26, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment