search

SylvainTI / wwwsqldesigner

Automatically exported from code.google.com/p/wwwsqldesigner
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Ability to choose in what format generate SQL #81

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
(new enhancement request)

Right now I understand that only the database specified in the XML source 
is made available for the "Generate SQL" button.

It would be nice to have a drop-down menu with the available output, so for 
exemple a loaded from postgresql model can easily generate SQL for mysql :)

[choose output v] [Generate SQL]
    mssql
    mysql
    oracle
    postgresql
    sqlalchemy
    sqllite
    vfp9
    web2py

I guess there is no limitation, since it is "simply" a XSL applied to the 
same XML, isn't it ?

Original issue reported on code.google.com by geompse@gmail.com on 16 Mar 2010 at 6:48

GoogleCodeExporter commented 9 years ago 
There are some datatype associations to be made... or maybe some warning to 
display ?

Original comment by geompse@gmail.com on 16 Mar 2010 at 6:50

GoogleCodeExporter commented 9 years ago 
In the past I have seen those posts :
  http://onlamp.com/pub/a/onlamp/2001/09/13/aboutSQL.html
  http://home.fnal.gov/~dbox/SQL_API_Portability.html
(scroll and look for type lists)

But maybe this issue can be skipped, if the database requested is not the 
XML's, basic 
types (int/char) shall be enough ?

Original comment by geompse@gmail.com on 16 Mar 2010 at 6:53

GoogleCodeExporter commented 9 years ago 
Using XSL which does not correspond to used datatype XML can introduce type 
values
which are not expected in the template. This will lead to undefined behavior.

There are always two distinct ways to take:

1) DB agnostic - the design is based on a common set of DB types without any
specificity. When exporting to SQL, user can pick his flavor.

2) DB specific - when creating new design, user must pick target SQL flavor. 
This is
later used in SQL generation.

WWW SQL Designer uses approach #2, as well as all other SQL designing tools I 
have
seen. I am afraid it is not possible to comfortably mix these two strategies.

Original comment by ondrej.zara on 17 Mar 2010 at 8:17