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=230...
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"?
Any ideas?
[0] http://sourceforge.net/tracker/?func=detail&aid=3141565&group_id=230...
2010/12/25 Marc Delisle marc@infomarc.info:
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"?
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.
Any ideas?
[0] http://sourceforge.net/tracker/?func=detail&aid=3141565&group_id=230...
-- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Sat, 25 Dec 2010 12:35:45 +0100 Dieter Adriaenssens dieter.adriaenssens@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.
2010/12/27 Michal Čihař michal@cihar.com:
Hi
Dne Sat, 25 Dec 2010 12:35:45 +0100 Dieter Adriaenssens dieter.adriaenssens@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.
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
-- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Mon, Dec 27, 2010 at 7:14 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Sat, 25 Dec 2010 12:35:45 +0100 Dieter Adriaenssens dieter.adriaenssens@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.
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.
-- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
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
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?
2010/12/27 AAMIR KHAN ak4u2009@gmail.com:
On Mon, Dec 27, 2010 at 7:14 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Sat, 25 Dec 2010 12:35:45 +0100 Dieter Adriaenssens dieter.adriaenssens@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.
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.
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&a...
Happy New Year!
Seasonal greetings,
Dieter
-- 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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
2010/12/31 Dieter Adriaenssens dieter.adriaenssens@gmail.com:
2010/12/27 AAMIR KHAN ak4u2009@gmail.com:
On Mon, Dec 27, 2010 at 7:14 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Sat, 25 Dec 2010 12:35:45 +0100 Dieter Adriaenssens dieter.adriaenssens@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.
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.
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&a...
Happy New Year!
Seasonal greetings,
Dieter
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
-
AAMIR KHAN -
Dieter Adriaenssens -
Marc Delisle -
Michal Čihař