From rouslan@placella.com Fri Jul 15 18:05:28 2011
From: Rouslan Placella <rouslan@placella.com>
To: developers@phpmyadmin.net
Subject: Re: [Phpmyadmin-devel] XML export
Date: Fri, 15 Jul 2011 19:05:16 +0100
Message-ID: <1310753116.2252.49.camel@roccivic-pc>
In-Reply-To:
 <CA+VATsxYui==i3ReovbE6ymOGF2n7shtr0i-PMJvMmngThsLFw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5263238833761224955=="

--===============5263238833761224955==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2011-07-15 at 20:00 +0200, Piotr Przybylski wrote:
> 2011/7/15 Rouslan Placella <rouslan(a)placella.com>:
> > On Thu, 2011-07-14 at 23:59 +0200, Piotr Przybylski wrote:
> >> 2011/7/14 Marc Delisle <marc(a)infomarc.info>:
> >> > Le 2011-07-14 15:43, Piotr Przybylski a =C3=A9crit :
> >> >> 2011/7/14 Marc Delisle<marc(a)infomarc.info>:
> >> >>> Le 2011-07-14 09:24, Piotr Przybylski a =C3=A9crit :
> >> >>>> 2011/7/14 Marc Delisle<marc(a)infomarc.info>:
> >> >>>>> Le 2011-07-13 18:28, Piotr Przybylski a =C3=A9crit :
> >> >>>>>> Hi,
> >> >>>>>>
> >> >>>>>> Is XML export used at all? It was missing data escaping in many
> >> >>>>>> places, and structure (table, function, ...) export was just brok=
en. I
> >> >>>>>> fixed it a bit, but there are still some problems that remain:
> >> >>>>>> - escaping of table/db names and data in other encodings than ISO=
-8859-1
> >> >>>>>> - it uses SHOW CREATE TABLE without any required fixes
> >> >>>>>>
> >> >>>>>> File format itself is interesting. I don't expect XML Schema for =
it to
> >> >>>>>> exist, but at least namespace usage should be consistent.
> >> >>>>>>
> >> >>>>>> I think fixing this and rewriting output format to be more consis=
tent
> >> >>>>>> should appear on Tasks for junior developers. And maybe extending=
 it
> >> >>>>>> to output data in more concise format, eg.:
> >> >>>>>> <table name=3D"">
> >> >>>>>> <row>
> >> >>>>>> <column_name>value</column_name>
> >> >>>>>> ...
> >> >>>>>> </row>
> >> >>>>>> ...
> >> >>>>>> </table>
> >> >>>>>>
> >> >>>>> Piotr,
> >> >>>>> XML export is probably used, how can we know?
> >> >>>>
> >> >>>> Maybe nobody needs DDL in it or we have too few people using it to
> >> >>>> report bugs :)
> >> >>>>
> >> >>>>> In your testing, was it just a problem in master or also in 3.4.x?
> >> >>>>>
> >> >>>>
> >> >>>> Also in 3.4.x (STABLE). Go to database `evil'"*/>` and try to export
> >> >>>> table `evil'"*/>` with all options selected. You will get only data
> >> >>>> (no structure) and invalid XML
> >> >>>
> >> >>> Can you backport your fixes to QA_3_4?
> >> >>>
> >> >>
> >> >> Yes. Just to be sure I don't break anything - what's the proper way o=
f doing it?
> >> >> 1. Create a local branch traacking origin/QA_3_4
> >> >> 2. cherry-pick my commits to master
> >> >> 3. push
> >> >> ?
> >> >>
> >> >
> >> > This should work.
> >>
> >> Thanks.
> >> > Usually you should have started with QA_3_4, like explained on
> >> > http://wiki.phpmyadmin.net/pma/Git#Committing_fixes_to_several_branche=
s.
> >>
> >> Too late now, I had to suffer from all these merge conflicts :)
> >>
> >> > The big mistake to avoid is merging master to QA_3_4!
> >>
> >> And this one would make an interesting merge conflict :D
> >
> > You forgot to merge QA_3_4 back into master after applying the fixes,
> > which I guess you didn't actually cherry-pick due to the differences in
> > whitespace distribution, so it left some interesting conflicts for the
> > next person merging QA_3_4 into master...
>=20
> Oops, sorry. Fortunately the correct way to resolve them was to use
> the file from master.

Then oops me too, because during the merge I used the hunks of code from
QA_3_4 when resolving conflicts. It made sense to me at the time to keep
the code from the two branches as similar to each other as possible...

Rouslan



--===============5263238833761224955==--