You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ddlutils-dev@db.apache.org by "Dave Sunerton-Burl (JIRA)" <ji...@apache.org> on 2007/03/15 12:03:09 UTC
[jira] Created: (DDLUTILS-164) Unicode datatypes not recognised by
databaseToDdl task
Unicode datatypes not recognised by databaseToDdl task
------------------------------------------------------
Key: DDLUTILS-164
URL: https://issues.apache.org/jira/browse/DDLUTILS-164
Project: DdlUtils
Issue Type: Bug
Components: Core - Oracle
Affects Versions: 1.0
Environment: WinXP
Reporter: Dave Sunerton-Burl
Assigned To: Thomas Dudziak
If you run the databaseToDdl task against Oracle 9.2 (using the oracle9 identifier), any unicode columns (e.g. NVARCHAR) come out in the XML as "OTHER". This means that it's impossible to recreate the database from the XML. Even "search and replace" doesn't work as BLOBs are read in as "OTHER" too, so there's no way to tell them apart (except manually with the real database in front of you!).
This is probably related to DDLUTILS-108. For creating a database from the XML, the most useful solution would be to allow a flag on the task which allows you to specify whether to use unicode versions or not. This would be on the *task*, not in the XML file. As discussed in DDLUTILS-108, databases tend to be set up with one language in mind and you might need to create schemas in different environments/languages from the same XML, so the XML needs to be language/unicode neutral. The situation we're in - maintaining a multi-lingual web application (where translations are in the database) - needs to use unicode columns. It is an all or nothing situation though - I don't see why you would choose to have some columns unicode (or a specific language) and not others - so a global setting outside of the XML would be fine.
For reading the DDL from the database, it's vital that unicode columns are recognised (i.e. NVARCHAR is recognised as JDBC VARCHAR). This is the important bit. If the columns aren't recognised to start with, then it's all over for automated database maintenance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DDLUTILS-164) Unicode datatypes not recognised by
databaseToDdl task
Posted by "Thomas Dudziak (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DDLUTILS-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Dudziak updated DDLUTILS-164:
------------------------------------
Fix Version/s: (was: 1.1)
1.2
> Unicode datatypes not recognised by databaseToDdl task
> ------------------------------------------------------
>
> Key: DDLUTILS-164
> URL: https://issues.apache.org/jira/browse/DDLUTILS-164
> Project: DdlUtils
> Issue Type: Improvement
> Components: Core (No specific database)
> Affects Versions: 1.0
> Environment: WinXP
> Reporter: Dave Sunerton-Burl
> Assignee: Thomas Dudziak
> Fix For: 1.2
>
>
> If you run the databaseToDdl task against Oracle 9.2 (using the oracle9 identifier), any unicode columns (e.g. NVARCHAR) come out in the XML as "OTHER". This means that it's impossible to recreate the database from the XML. Even "search and replace" doesn't work as BLOBs are read in as "OTHER" too, so there's no way to tell them apart (except manually with the real database in front of you!).
> This is probably related to DDLUTILS-108. For creating a database from the XML, the most useful solution would be to allow a flag on the task which allows you to specify whether to use unicode versions or not. This would be on the *task*, not in the XML file. As discussed in DDLUTILS-108, databases tend to be set up with one language in mind and you might need to create schemas in different environments/languages from the same XML, so the XML needs to be language/unicode neutral. The situation we're in - maintaining a multi-lingual web application (where translations are in the database) - needs to use unicode columns. It is an all or nothing situation though - I don't see why you would choose to have some columns unicode (or a specific language) and not others - so a global setting outside of the XML would be fine.
> For reading the DDL from the database, it's vital that unicode columns are recognised (i.e. NVARCHAR is recognised as JDBC VARCHAR). This is the important bit. If the columns aren't recognised to start with, then it's all over for automated database maintenance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DDLUTILS-164) Unicode datatypes not recognised by
databaseToDdl task
Posted by "Thomas Dudziak (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DDLUTILS-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Dudziak updated DDLUTILS-164:
------------------------------------
Fix Version/s: 1.1
Issue Type: Improvement (was: Bug)
> Unicode datatypes not recognised by databaseToDdl task
> ------------------------------------------------------
>
> Key: DDLUTILS-164
> URL: https://issues.apache.org/jira/browse/DDLUTILS-164
> Project: DdlUtils
> Issue Type: Improvement
> Components: Core (No specific database)
> Affects Versions: 1.0
> Environment: WinXP
> Reporter: Dave Sunerton-Burl
> Assigned To: Thomas Dudziak
> Fix For: 1.1
>
>
> If you run the databaseToDdl task against Oracle 9.2 (using the oracle9 identifier), any unicode columns (e.g. NVARCHAR) come out in the XML as "OTHER". This means that it's impossible to recreate the database from the XML. Even "search and replace" doesn't work as BLOBs are read in as "OTHER" too, so there's no way to tell them apart (except manually with the real database in front of you!).
> This is probably related to DDLUTILS-108. For creating a database from the XML, the most useful solution would be to allow a flag on the task which allows you to specify whether to use unicode versions or not. This would be on the *task*, not in the XML file. As discussed in DDLUTILS-108, databases tend to be set up with one language in mind and you might need to create schemas in different environments/languages from the same XML, so the XML needs to be language/unicode neutral. The situation we're in - maintaining a multi-lingual web application (where translations are in the database) - needs to use unicode columns. It is an all or nothing situation though - I don't see why you would choose to have some columns unicode (or a specific language) and not others - so a global setting outside of the XML would be fine.
> For reading the DDL from the database, it's vital that unicode columns are recognised (i.e. NVARCHAR is recognised as JDBC VARCHAR). This is the important bit. If the columns aren't recognised to start with, then it's all over for automated database maintenance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DDLUTILS-164) Unicode datatypes not recognised by
databaseToDdl task
Posted by "Thomas Dudziak (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DDLUTILS-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Dudziak updated DDLUTILS-164:
------------------------------------
Component/s: (was: Core - Oracle)
Core (No specific database)
> Unicode datatypes not recognised by databaseToDdl task
> ------------------------------------------------------
>
> Key: DDLUTILS-164
> URL: https://issues.apache.org/jira/browse/DDLUTILS-164
> Project: DdlUtils
> Issue Type: Improvement
> Components: Core (No specific database)
> Affects Versions: 1.0
> Environment: WinXP
> Reporter: Dave Sunerton-Burl
> Assigned To: Thomas Dudziak
> Fix For: 1.1
>
>
> If you run the databaseToDdl task against Oracle 9.2 (using the oracle9 identifier), any unicode columns (e.g. NVARCHAR) come out in the XML as "OTHER". This means that it's impossible to recreate the database from the XML. Even "search and replace" doesn't work as BLOBs are read in as "OTHER" too, so there's no way to tell them apart (except manually with the real database in front of you!).
> This is probably related to DDLUTILS-108. For creating a database from the XML, the most useful solution would be to allow a flag on the task which allows you to specify whether to use unicode versions or not. This would be on the *task*, not in the XML file. As discussed in DDLUTILS-108, databases tend to be set up with one language in mind and you might need to create schemas in different environments/languages from the same XML, so the XML needs to be language/unicode neutral. The situation we're in - maintaining a multi-lingual web application (where translations are in the database) - needs to use unicode columns. It is an all or nothing situation though - I don't see why you would choose to have some columns unicode (or a specific language) and not others - so a global setting outside of the XML would be fine.
> For reading the DDL from the database, it's vital that unicode columns are recognised (i.e. NVARCHAR is recognised as JDBC VARCHAR). This is the important bit. If the columns aren't recognised to start with, then it's all over for automated database maintenance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.