[JBoss JIRA] (TEIIDDES-1211) Exporting DDL for Postgres produces invalid CREATE INDEX statement because duplicate object names in database
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-1211?page=com.atlassian.jira.plu... ]
Barry LaFond updated TEIIDDES-1211:
-----------------------------------
Fix Version/s: 8.2
> Exporting DDL for Postgres produces invalid CREATE INDEX statement because duplicate object names in database
> -------------------------------------------------------------------------------------------------------------
>
> Key: TEIIDDES-1211
> URL: https://issues.jboss.org/browse/TEIIDDES-1211
> Project: Teiid Designer
> Issue Type: Bug
> Components: Import/Export
> Affects Versions: 7.4.2
> Reporter: Van Halbert
> Fix For: 8.2
>
> Attachments: tpc_postgres.ddl
>
>
> Trying to execute DDL on postgres database produces this error:
> Error: ERROR: relation "orders" already exists
> SQLState: 42P07
> ErrorCode: 0
> Error occured in:
> CREATE INDEX ORDERS ON ORDERS (O_CUSTKEY)
> ----
> The problem was resolved if I changed ORDERS index name:
>
> CREATE INDEX ORDERS_IDX ON ORDERS (O_CUSTKEY);
> ----
> Here's a statement I found on the Postgres Naming rules:
> The names of all objects must be unique within some scope. Every database must have a unique name; the name of a schema must be unique within the scope of a single database, the name of a table must be unique within the scope of a single schema, and column names must be unique within a table. The name of an index must be unique within a database.
> I would like to suggest that all index names that are created are appended with "idx" or something similar. Right now, the first looks to be the name of the table, and subsequent names have 1,2, etc. appended.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (TEIIDDES-1211) Exporting DDL for Postgres produces invalid CREATE INDEX statement because duplicate object names in database
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-1211?page=com.atlassian.jira.plu... ]
Barry LaFond commented on TEIIDDES-1211:
----------------------------------------
The fix for this would be to create a new RelationalChildrenNameValidationRule or something like that to check for duplicate names for TABLES, PROCEDURES, INDEXES and VIEWS. Looks like we already compare VIEW and TABLE names, so maybe just add procedures and indexes to the check.
Users will still be responsible for fixing these name conflicts (if exists) brefore EXPORTING DDL
> Exporting DDL for Postgres produces invalid CREATE INDEX statement because duplicate object names in database
> -------------------------------------------------------------------------------------------------------------
>
> Key: TEIIDDES-1211
> URL: https://issues.jboss.org/browse/TEIIDDES-1211
> Project: Teiid Designer
> Issue Type: Bug
> Components: Import/Export
> Affects Versions: 7.4.2
> Reporter: Van Halbert
> Attachments: tpc_postgres.ddl
>
>
> Trying to execute DDL on postgres database produces this error:
> Error: ERROR: relation "orders" already exists
> SQLState: 42P07
> ErrorCode: 0
> Error occured in:
> CREATE INDEX ORDERS ON ORDERS (O_CUSTKEY)
> ----
> The problem was resolved if I changed ORDERS index name:
>
> CREATE INDEX ORDERS_IDX ON ORDERS (O_CUSTKEY);
> ----
> Here's a statement I found on the Postgres Naming rules:
> The names of all objects must be unique within some scope. Every database must have a unique name; the name of a schema must be unique within the scope of a single database, the name of a table must be unique within the scope of a single schema, and column names must be unique within a table. The name of an index must be unique within a database.
> I would like to suggest that all index names that are created are appended with "idx" or something similar. Right now, the first looks to be the name of the table, and subsequent names have 1,2, etc. appended.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (TEIIDDES-1211) Exporting DDL for Postgres produces invalid CREATE INDEX statement because duplicate object names in database
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-1211?page=com.atlassian.jira.plu... ]
Barry LaFond updated TEIIDDES-1211:
-----------------------------------
Assignee: Dan Florian
> Exporting DDL for Postgres produces invalid CREATE INDEX statement because duplicate object names in database
> -------------------------------------------------------------------------------------------------------------
>
> Key: TEIIDDES-1211
> URL: https://issues.jboss.org/browse/TEIIDDES-1211
> Project: Teiid Designer
> Issue Type: Bug
> Components: Import/Export
> Affects Versions: 7.4.2
> Reporter: Van Halbert
> Assignee: Dan Florian
> Fix For: 8.2
>
> Attachments: tpc_postgres.ddl
>
>
> Trying to execute DDL on postgres database produces this error:
> Error: ERROR: relation "orders" already exists
> SQLState: 42P07
> ErrorCode: 0
> Error occured in:
> CREATE INDEX ORDERS ON ORDERS (O_CUSTKEY)
> ----
> The problem was resolved if I changed ORDERS index name:
>
> CREATE INDEX ORDERS_IDX ON ORDERS (O_CUSTKEY);
> ----
> Here's a statement I found on the Postgres Naming rules:
> The names of all objects must be unique within some scope. Every database must have a unique name; the name of a schema must be unique within the scope of a single database, the name of a table must be unique within the scope of a single schema, and column names must be unique within a table. The name of an index must be unique within a database.
> I would like to suggest that all index names that are created are appended with "idx" or something similar. Right now, the first looks to be the name of the table, and subsequent names have 1,2, etc. appended.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (TEIIDDES-1176) Usability Issue: On DDL importer, need better feed back when a file cannot be imported
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-1176?page=com.atlassian.jira.plu... ]
Barry LaFond updated TEIIDDES-1176:
-----------------------------------
Assignee: Mark Drilling
> Usability Issue: On DDL importer, need better feed back when a file cannot be imported
> --------------------------------------------------------------------------------------
>
> Key: TEIIDDES-1176
> URL: https://issues.jboss.org/browse/TEIIDDES-1176
> Project: Teiid Designer
> Issue Type: Bug
> Components: Import/Export
> Affects Versions: 7.4.2
> Reporter: Van Halbert
> Assignee: Mark Drilling
> Fix For: 8.2
>
> Attachments: Testfile.ddl
>
>
> When importing a DDL file, the importer fails. Its hard to determine where the problem is in the file. It was suggested it would be nice if it could parse what it can and then indicate after which statement it failed.
> Also, it would be nice to be able to select which objects (like the jdbc importer of selecting tables, indexes, etc.) to import. Maybe the ddl importer could utilize part the jdbc importer wizard to provide the same options.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (TEIIDDES-1176) Usability Issue: On DDL importer, need better feed back when a file cannot be imported
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-1176?page=com.atlassian.jira.plu... ]
Barry LaFond updated TEIIDDES-1176:
-----------------------------------
Fix Version/s: 8.2
> Usability Issue: On DDL importer, need better feed back when a file cannot be imported
> --------------------------------------------------------------------------------------
>
> Key: TEIIDDES-1176
> URL: https://issues.jboss.org/browse/TEIIDDES-1176
> Project: Teiid Designer
> Issue Type: Bug
> Components: Import/Export
> Affects Versions: 7.4.2
> Reporter: Van Halbert
> Fix For: 8.2
>
> Attachments: Testfile.ddl
>
>
> When importing a DDL file, the importer fails. Its hard to determine where the problem is in the file. It was suggested it would be nice if it could parse what it can and then indicate after which statement it failed.
> Also, it would be nice to be able to select which objects (like the jdbc importer of selecting tables, indexes, etc.) to import. Maybe the ddl importer could utilize part the jdbc importer wizard to provide the same options.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (TEIIDDES-1387) Encountered NPE during XML Remote import
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-1387?page=com.atlassian.jira.plu... ]
Barry LaFond updated TEIIDDES-1387:
-----------------------------------
Assignee: Ted Jones
> Encountered NPE during XML Remote import
> ----------------------------------------
>
> Key: TEIIDDES-1387
> URL: https://issues.jboss.org/browse/TEIIDDES-1387
> Project: Teiid Designer
> Issue Type: Bug
> Components: Import/Export
> Affects Versions: 7.7.1
> Reporter: Mark Drilling
> Assignee: Ted Jones
> Fix For: 8.2
>
> Attachments: PlantCatException.txt
>
>
> Encountered NPE during import of the PlantCatalog remote XML file example - http://www.w3schools.com/xml/plant_catalog.xml
> I think the issue was - I added the Plant child Elements, but left the 'root path' at the document root. However, when I re-tried the scenario - I didnt get the NPE again. Anyway, I am attaching the stacktrace - we may be able to figure out the issue from that.
> This may be something we want to address for usability - maybe we can do some validation to ensure that the root path is appropriate for the selected elements?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (TEIIDDES-1474) Preview Data on certain models causes JBDS to go into unrecoverable loop
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-1474?page=com.atlassian.jira.plu... ]
Barry LaFond updated TEIIDDES-1474:
-----------------------------------
Fix Version/s: 8.2
> Preview Data on certain models causes JBDS to go into unrecoverable loop
> ------------------------------------------------------------------------
>
> Key: TEIIDDES-1474
> URL: https://issues.jboss.org/browse/TEIIDDES-1474
> Project: Teiid Designer
> Issue Type: Bug
> Components: Data Preview
> Affects Versions: 7.1.1
> Environment: Have attempted on both RHEL 6.3 and Mac OSX. Used JBDS 5.0 with latest plugins and EDS 5.3.
> Reporter: Blaine Mincey
> Fix For: 8.2
>
>
> When using the FinancialsDemo, our internal demo project (https://docspace.corp.redhat.com/docs/DOC-56653), previewing data from the CustomerHoldings/BrokerageModel (models AccountHoldings, AccountValue, and HighNetWorthCustomers) causes JBDS/Teiid to go into an unrecoverable loop where you must abruptly "force quit" the IDE to regain control. I have also seen this behavior when attempting to preview data from one of the included Web Services in the project.
> The following snippet is repeated multiple times in the EDS server log at the time that the process seems to get stuck in a loop:
> 2012-08-15 15:10:29,866 INFO [org.teiid.RUNTIME] (New I/O server worker #2-1) org.teiid.query.tempdata.GlobalTableStoreImpl@644ec403 first member or timeout exceeded
> 2012-08-15 15:10:29,881 INFO [org.teiid.PROCESSOR] (New I/O server worker #2-1) Clearing prepared plan cache for vdb PREVIEW_70a7a0cb-5c46-4589-aa1c-9018517e0c0f_FinancialsDemo_project.1
> 2012-08-15 15:10:29,882 INFO [org.teiid.PROCESSOR] (New I/O server worker #2-1) Clearing the resultset cache for vdb PREVIEW_70a7a0cb-5c46-4589-aa1c-9018517e0c0f_FinancialsDemo_project.1
> 2012-08-15 15:10:29,896 INFO [STDOUT] (New I/O server worker #2-1)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (TEIIDDES-1474) Preview Data on certain models causes JBDS to go into unrecoverable loop
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-1474?page=com.atlassian.jira.plu... ]
Barry LaFond updated TEIIDDES-1474:
-----------------------------------
Assignee: Paul Richardson
> Preview Data on certain models causes JBDS to go into unrecoverable loop
> ------------------------------------------------------------------------
>
> Key: TEIIDDES-1474
> URL: https://issues.jboss.org/browse/TEIIDDES-1474
> Project: Teiid Designer
> Issue Type: Bug
> Components: Data Preview
> Affects Versions: 7.1.1
> Environment: Have attempted on both RHEL 6.3 and Mac OSX. Used JBDS 5.0 with latest plugins and EDS 5.3.
> Reporter: Blaine Mincey
> Assignee: Paul Richardson
> Fix For: 8.2
>
>
> When using the FinancialsDemo, our internal demo project (https://docspace.corp.redhat.com/docs/DOC-56653), previewing data from the CustomerHoldings/BrokerageModel (models AccountHoldings, AccountValue, and HighNetWorthCustomers) causes JBDS/Teiid to go into an unrecoverable loop where you must abruptly "force quit" the IDE to regain control. I have also seen this behavior when attempting to preview data from one of the included Web Services in the project.
> The following snippet is repeated multiple times in the EDS server log at the time that the process seems to get stuck in a loop:
> 2012-08-15 15:10:29,866 INFO [org.teiid.RUNTIME] (New I/O server worker #2-1) org.teiid.query.tempdata.GlobalTableStoreImpl@644ec403 first member or timeout exceeded
> 2012-08-15 15:10:29,881 INFO [org.teiid.PROCESSOR] (New I/O server worker #2-1) Clearing prepared plan cache for vdb PREVIEW_70a7a0cb-5c46-4589-aa1c-9018517e0c0f_FinancialsDemo_project.1
> 2012-08-15 15:10:29,882 INFO [org.teiid.PROCESSOR] (New I/O server worker #2-1) Clearing the resultset cache for vdb PREVIEW_70a7a0cb-5c46-4589-aa1c-9018517e0c0f_FinancialsDemo_project.1
> 2012-08-15 15:10:29,896 INFO [STDOUT] (New I/O server worker #2-1)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months