25 Dec
2010
25 Dec
'10
6:35 a.m.
Hi all,
I'd like your opinion about exporting view of view in xml format.
Aamir Khan prepared a patch [0] that creates an XML export in the way
this is handled in SQL export, ie first all tables and views are
exported. All views are exported as standin tables with the same
structure. Then all views are recreated, first dropping the standin
tables, and creating the real views. The reason for this is to make
sure that when creating a view that uses another view, it at least
exists, thus avoiding an error upon importing it again.
Downside of this is that the xml export of the structure schema gets a
bit confusing with a <pma:table>, <pma:drop> and <pma:view> tag for
every view, as the xml export is intended to be used by custom
scripting.
Another idea is just to export the schema structure with one tag for a
view (without the extra table and drop parts), and make some changes
to the xml import code, to handle the correct creation of the views.
Any ideas?
[0]
http://sourceforge.net/tracker/?func=detail&aid=3141565&group_id=23…
--
Kind regards and Merry Christmas,
Dieter Adriaenssens
25 Dec
25 Dec
3:01 p.m.
Le 2010-12-25 06:35, Dieter Adriaenssens a écrit :
Hi all,
I'd like your opinion about exporting view of view in xml format.
Aamir Khan prepared a patch [0] that creates an XML export in the way
this is handled in SQL export, ie first all tables and views are
exported. All views are exported as standin tables with the same
structure. Then all views are recreated, first dropping the standin
tables, and creating the real views. The reason for this is to make
sure that when creating a view that uses another view, it at least
exists, thus avoiding an error upon importing it again.
Downside of this is that the xml export of the structure schema gets a
bit confusing with a <pma:table>, <pma:drop> and <pma:view> tag for
every view, as the xml export is intended to be used by custom
scripting.
Another idea is just to export the schema structure with one tag for a
view (without the extra table and drop parts), and make some changes
to the xml import code, to handle the correct creation of the views.
Has a patch been contributed to implement this second idea? If not, how
complex would be "some changes"?
--
Marc Delisle
http://infomarc.info
27 Dec
27 Dec
8:50 a.m.
2010/12/25 Marc Delisle <marc(a)infomarc.info>fo>:
Le 2010-12-25 06:35, Dieter Adriaenssens a écrit :
There is no patch yet.
Currently the import/xml.php code executes the SQL statements that are
defined in the structure schema in the exported XML file (see
attachment for an example, which was generated with Aamir's patch).
'Some changes' would mean that the import would have to detect a view
and generate the stand-in table for it, and after creating all
tables/stand-in views, executing the SQL statements to create the real
views (and add a a DROP statement of that stand-in table)
It doesn't seem to be too complex.
Hi all,
I'd like your opinion about exporting view of view in xml format.
Aamir Khan prepared a patch [0] that creates an XML export in the way
this is handled in SQL export, ie first all tables and views are
exported. All views are exported as standin tables with the same
structure. Then all views are recreated, first dropping the standin
tables, and creating the real views. The reason for this is to make
sure that when creating a view that uses another view, it at least
exists, thus avoiding an error upon importing it again.
Downside of this is that the xml export of the structure schema gets a
bit confusing with a <pma:table>, <pma:drop> and <pma:view> tag for
every view, as the xml export is intended to be used by custom
scripting.
Another idea is just to export the schema structure with one tag for a
view (without the extra table and drop parts), and make some changes
to the xml import code, to handle the correct creation of the views.
Has a patch been contributed to implement this second idea? If not, how
complex would be "some changes"?
--
Marc Delisle
http://infomarc.info
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
--
Groetjes,
Dieter Adriaenssens
8:44 a.m.
Hi
Dne Sat, 25 Dec 2010 12:35:45 +0100
Dieter Adriaenssens <dieter.adriaenssens(a)gmail.com> napsal(a):
I'd like your opinion about exporting view of view
in xml format.
Aamir Khan prepared a patch [0] that creates an XML export in the way
this is handled in SQL export, ie first all tables and views are
exported. All views are exported as standin tables with the same
structure. Then all views are recreated, first dropping the standin
tables, and creating the real views. The reason for this is to make
sure that when creating a view that uses another view, it at least
exists, thus avoiding an error upon importing it again.
Downside of this is that the xml export of the structure schema gets a
bit confusing with a <pma:table>, <pma:drop> and <pma:view> tag for
every view, as the xml export is intended to be used by custom
scripting.
I don't think that XML should be replacement of the SQL, especially I
don't see need for <pma:drop>. So it should just describe the data and
import should handle such problems.
--
Michal Čihař | http://cihar.com | http://phpmyadmin.cz
8:54 a.m.
2010/12/27 Michal Čihař <michal(a)cihar.com>om>:
Hi
Dne Sat, 25 Dec 2010 12:35:45 +0100
Dieter Adriaenssens <dieter.adriaenssens(a)gmail.com> napsal(a):
I agree. The XML export should be as clear as possible, with just one
entry for every instance (be it a table, database, view, function, or
data record (row)).
Kind regards,
Dieter
I'd like your opinion about exporting view of
view in xml format.
Aamir Khan prepared a patch [0] that creates an XML export in the way
this is handled in SQL export, ie first all tables and views are
exported. All views are exported as standin tables with the same
structure. Then all views are recreated, first dropping the standin
tables, and creating the real views. The reason for this is to make
sure that when creating a view that uses another view, it at least
exists, thus avoiding an error upon importing it again.
Downside of this is that the xml export of the structure schema gets a
bit confusing with a <pma:table>, <pma:drop> and <pma:view> tag for
every view, as the xml export is intended to be used by custom
scripting.
I don't think that XML should be replacement of the SQL, especially I
don't see need for <pma:drop>. So it should just describe the data and
import should handle such problems.
--
Michal Čihař | http://cihar.com | http://phpmyadmin.cz
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
--
Groetjes,
Dieter Adriaenssens
3:42 p.m.
On Mon, Dec 27, 2010 at 7:14 PM, Michal Čihař <michal(a)cihar.com> wrote:
Hi
Dne Sat, 25 Dec 2010 12:35:45 +0100
Dieter Adriaenssens <dieter.adriaenssens(a)gmail.com> napsal(a):
I have created one test XML file as well as patch to implement
<pma:drop-stand-in> previously <pma:drop> as children of the
<pma:view> and renamed the tag names to make less confusion.
I'd like your opinion about exporting view of
view in xml format.
Aamir Khan prepared a patch [0] that creates an XML export in the way
this is handled in SQL export, ie first all tables and views are
exported. All views are exported as standin tables with the same
structure. Then all views are recreated, first dropping the standin
tables, and creating the real views. The reason for this is to make
sure that when creating a view that uses another view, it at least
exists, thus avoiding an error upon importing it again.
Downside of this is that the xml export of the structure schema gets a
bit confusing with a <pma:table>, <pma:drop> and <pma:view> tag for
every view, as the xml export is intended to be used by custom
scripting.
I don't think that XML should be replacement of the SQL, especially I
don't see need for <pma:drop>. So it should just describe the data and
import should handle such problems.
--
Michal Čihař | http://cihar.com | http://phpmyadmin.cz
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
29 Dec
29 Dec
11:48 p.m.
Hey i have got one bounce mail saying that moderator should allow you
to send so much bulky message to the list...actually it was attachment
which is bulky since its export of somewhat large database.
And what are your views regarding the above nested XML structure for views?
____
Regards
Aamir Khan
30 Dec
30 Dec
6 a.m.
Le 2010-12-29 23:48, AAMIR KHAN a écrit :
Hey i have got one bounce mail saying that moderator
should allow you
to send so much bulky message to the list...actually it was attachment
which is bulky since its export of somewhat large database.
Yes, this limit is normal and better than encumbering all subscribers'
mailbox. You could go to our Patches tracker and attach your file there,
then send the reference to the list.
And what are your views regarding the above nested XML structure for views?
--
Marc Delisle
http://infomarc.info
31 Dec
31 Dec
10:52 a.m.
2010/12/27 AAMIR KHAN <ak4u2009(a)gmail.com>om>:
--
Groetjes,
Dieter Adriaenssens
On Mon, Dec 27, 2010 at 7:14 PM, Michal Čihař
<michal(a)cihar.com> wrote:
Hi Aamir,
I took a look at your patch (xml-view-nested.diff [0]). I don't
understand why you keep the stand-in and stand-in-drop in the export,
if you go to the trouble of changing the import process to take care
of the nested stand-in-drop. Wouldn't it be easier to just have an
export of <pma:view> (without stand-in or drop) and make the necessary
changes in import to take care of the view of view problem? (I
described how this should work in an earlier post)
[0]
http://sourceforge.net/tracker/download.php?group_id=23067&atid=377410&…
Happy New Year!
Seasonal greetings,
Dieter
Hi
Dne Sat, 25 Dec 2010 12:35:45 +0100
Dieter Adriaenssens <dieter.adriaenssens(a)gmail.com> napsal(a):
I have created one test XML file as well as patch to implement
<pma:drop-stand-in> previously <pma:drop> as children of the
<pma:view> and renamed the tag names to make less confusion. I'd like your opinion about exporting view of
view in xml format.
Aamir Khan prepared a patch [0] that creates an XML export in the way
this is handled in SQL export, ie first all tables and views are
exported. All views are exported as standin tables with the same
structure. Then all views are recreated, first dropping the standin
tables, and creating the real views. The reason for this is to make
sure that when creating a view that uses another view, it at least
exists, thus avoiding an error upon importing it again.
Downside of this is that the xml export of the structure schema gets a
bit confusing with a <pma:table>, <pma:drop> and <pma:view> tag for
every view, as the xml export is intended to be used by custom
scripting.
I don't think that XML should be replacement of the SQL, especially I
don't see need for <pma:drop>. So it should just describe the data and
import should handle such problems.
--
Michal Čihař | http://cihar.com | http://phpmyadmin.cz
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
8 Feb
8 Feb
1:48 p.m.
2010/12/31 Dieter Adriaenssens <dieter.adriaenssens(a)gmail.com>om>:
2010/12/27 AAMIR KHAN <ak4u2009(a)gmail.com>om>:
Hi Aamir,
I hope you are doing fine.
Are you still working on a patch for the xml export/import of views?
Kind regards,
Dieter
On Mon, Dec 27, 2010 at 7:14 PM, Michal Čihař
<michal(a)cihar.com> wrote:
Hi Aamir,
I took a look at your patch (xml-view-nested.diff [0]). I don't
understand why you keep the stand-in and stand-in-drop in the export,
if you go to the trouble of changing the import process to take care
of the nested stand-in-drop. Wouldn't it be easier to just have an
export of <pma:view> (without stand-in or drop) and make the necessary
changes in import to take care of the view of view problem? (I
described how this should work in an earlier post)
[0]
http://sourceforge.net/tracker/download.php?group_id=23067&atid=377410&…
Happy New Year!
Seasonal greetings,
Dieter
Hi
Dne Sat, 25 Dec 2010 12:35:45 +0100
Dieter Adriaenssens <dieter.adriaenssens(a)gmail.com> napsal(a):
I have created one test XML file as well as patch to implement
<pma:drop-stand-in> previously <pma:drop> as children of the
<pma:view> and renamed the tag names to make less confusion. I'd like your opinion about exporting view of
view in xml format.
Aamir Khan prepared a patch [0] that creates an XML export in the way
this is handled in SQL export, ie first all tables and views are
exported. All views are exported as standin tables with the same
structure. Then all views are recreated, first dropping the standin
tables, and creating the real views. The reason for this is to make
sure that when creating a view that uses another view, it at least
exists, thus avoiding an error upon importing it again.
Downside of this is that the xml export of the structure schema gets a
bit confusing with a <pma:table>, <pma:drop> and <pma:view> tag for
every view, as the xml export is intended to be used by custom
scripting.
I don't think that XML should be replacement of the SQL, especially I
don't see need for <pma:drop>. So it should just describe the data and
import should handle such problems.
4918
days inactive
4963
days old
9 comments
4 participants
participants (4)
-
AAMIR KHAN -
Dieter Adriaenssens -
Marc Delisle -
Michal Čihař