[JBoss JIRA] (TEIIDDES-2861) Import DDL option is confusing
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-2861?page=com.atlassian.jira.plu... ]
Barry LaFond commented on TEIIDDES-2861:
----------------------------------------
[~van.halbert] note that importing DDL means importing a DDL file, not a dynamic-vdb.xml file. Importing Dynamic VDBs isn't a feature, but generating an archive VDB from a dynamic VDB in your project is a features : *Modeling > Generate Archive VDB*
> Import DDL option is confusing
> ------------------------------
>
> Key: TEIIDDES-2861
> URL: https://issues.jboss.org/browse/TEIIDDES-2861
> Project: Teiid Designer
> Issue Type: Bug
> Components: Import/Export
> Affects Versions: 10.0.2
> Reporter: Van Halbert
> Attachments: jdg-remote-cache-mat-vdb.xml, portfolio-vdb.xml
>
>
> Have the following comments when trying to use the DDL importer to import a dynamic vdb:
> - It refers to everything as DDL, when dynamic vdb is not
> - the file chooser defaults to DDL, when maybe it should have an option for .xml
> - on the importer, there's a Mode type. When importing dynamic VDB's, this shouldn't apply, because the dynamic vdb can have both virtual and source models.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (TEIIDDES-2860) deleting MATVIEW deletes the upper view model
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-2860?page=com.atlassian.jira.plu... ]
Barry LaFond commented on TEIIDDES-2860:
----------------------------------------
[~van.halbert] There are currently no checks to look for existing table name... I could certainly add that step to "replace" the mat. source table prior to finishing the process (i.e. setting the table refer. to the new source table, etc.)
> deleting MATVIEW deletes the upper view model
> ---------------------------------------------
>
> Key: TEIIDDES-2860
> URL: https://issues.jboss.org/browse/TEIIDDES-2860
> Project: Teiid Designer
> Issue Type: Bug
> Components: Modeling
> Affects Versions: 10.0.2
> Reporter: Van Halbert
> Assignee: Barry LaFond
> Priority: Blocker
>
> When deleting MATVIEW it also wants to delete the view model from where it came. You should be able to delete the MATVIEW table and rerun the MATVIEW creation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (TEIIDDES-2860) deleting MATVIEW deletes the upper view model
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-2860?page=com.atlassian.jira.plu... ]
Van Halbert commented on TEIIDDES-2860:
---------------------------------------
This is a major issue in the usability of the reiterative process of developing what is materialized. Especially with the JDG materialization, it will duplicate the matview source table, instead of updating. So there's no way to delete the matview source table(s) without deleting the view.
> deleting MATVIEW deletes the upper view model
> ---------------------------------------------
>
> Key: TEIIDDES-2860
> URL: https://issues.jboss.org/browse/TEIIDDES-2860
> Project: Teiid Designer
> Issue Type: Bug
> Components: Modeling
> Affects Versions: 10.0.2
> Reporter: Van Halbert
> Assignee: Barry LaFond
> Priority: Blocker
>
> When deleting MATVIEW it also wants to delete the view model from where it came. You should be able to delete the MATVIEW table and rerun the MATVIEW creation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (TEIIDDES-2812) Add ability to reverse engineer into a Pojo object from a table or view
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-2812?page=com.atlassian.jira.plu... ]
Van Halbert commented on TEIIDDES-2812:
---------------------------------------
Comments:
- Ramesh is right, for repetitive process of creating the view you want to be materialized, as well as, adjusting it over time, may want to make the creation of the module zip optional. Because once the module is created and deployed, the user will just need to recreate the jar for deployment. No need to go thru the steps of deploying the zip again.
- which means, we may want to use a different descriptor for the menu option of "Generate materialize JDG module"
- Also, another jira was logged related to when the materialized source table is deleted, it has to delete the view table. This is bad. The view table is created based on the business view of the world, independent of a need for materialization. These two tables should not be linked together in the notion that if the matview source table is deleted, the view also has to be deleted.
> Add ability to reverse engineer into a Pojo object from a table or view
> -----------------------------------------------------------------------
>
> Key: TEIIDDES-2812
> URL: https://issues.jboss.org/browse/TEIIDDES-2812
> Project: Teiid Designer
> Issue Type: Feature Request
> Components: Modeling, Usability
> Affects Versions: 9.0.6
> Reporter: Van Halbert
> Assignee: Barry LaFond
> Priority: Blocker
> Fix For: 10.0.2
>
>
> The scenario is: select table/view, right mouse click select Create Pojo, present dialog, need a file chooser to select location to save output.
> Label of action: Create Pojo (or something to indicates the process)
> Dialog title: Create Pojo from Table [tableName]
> Message: This will create a Pojo class, and packaged in a jar, that is meant to be used when JDG will be used in materialization or accessed as a data source.
> Options:
> - file chooser option to select folder to save pojo jar
> - drop-down: <select option>
> Access JDG in Library Mode
> Access JDG via Hot Rod Client
> - pojo package name (default = org.teiid.pojo)
> - pojo jar name (default = pojo.jar)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (TEIIDDES-2861) Import DDL option is confusing
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-2861?page=com.atlassian.jira.plu... ]
Van Halbert commented on TEIIDDES-2861:
---------------------------------------
When importing and the model contains extension properties, the process should automatically register them if the do not exist. The user shouldn't have to open the model and work thru registering them, before they can import.
> Import DDL option is confusing
> ------------------------------
>
> Key: TEIIDDES-2861
> URL: https://issues.jboss.org/browse/TEIIDDES-2861
> Project: Teiid Designer
> Issue Type: Bug
> Components: Import/Export
> Affects Versions: 10.0.2
> Reporter: Van Halbert
> Attachments: jdg-remote-cache-mat-vdb.xml, portfolio-vdb.xml
>
>
> Have the following comments when trying to use the DDL importer to import a dynamic vdb:
> - It refers to everything as DDL, when dynamic vdb is not
> - the file chooser defaults to DDL, when maybe it should have an option for .xml
> - on the importer, there's a Mode type. When importing dynamic VDB's, this shouldn't apply, because the dynamic vdb can have both virtual and source models.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (TEIIDDES-2861) Import DDL option is confusing
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-2861?page=com.atlassian.jira.plu... ]
Van Halbert updated TEIIDDES-2861:
----------------------------------
Attachment: portfolio-vdb.xml
jdg-remote-cache-mat-vdb.xml
Also, attaching 2 dynamic vdb's. the jdg-remote-cache-mat-vdb.xml reuses the portfolio-vdb.xml.
> Import DDL option is confusing
> ------------------------------
>
> Key: TEIIDDES-2861
> URL: https://issues.jboss.org/browse/TEIIDDES-2861
> Project: Teiid Designer
> Issue Type: Bug
> Components: Import/Export
> Affects Versions: 10.0.2
> Reporter: Van Halbert
> Attachments: jdg-remote-cache-mat-vdb.xml, portfolio-vdb.xml
>
>
> Have the following comments when trying to use the DDL importer to import a dynamic vdb:
> - It refers to everything as DDL, when dynamic vdb is not
> - the file chooser defaults to DDL, when maybe it should have an option for .xml
> - on the importer, there's a Mode type. When importing dynamic VDB's, this shouldn't apply, because the dynamic vdb can have both virtual and source models.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (TEIIDDES-2861) Import DDL option is confusing
by Van Halbert (JIRA)
Van Halbert created TEIIDDES-2861:
-------------------------------------
Summary: Import DDL option is confusing
Key: TEIIDDES-2861
URL: https://issues.jboss.org/browse/TEIIDDES-2861
Project: Teiid Designer
Issue Type: Bug
Components: Import/Export
Affects Versions: 10.0.2
Reporter: Van Halbert
Have the following comments when trying to use the DDL importer to import a dynamic vdb:
- It refers to everything as DDL, when dynamic vdb is not
- the file chooser defaults to DDL, when maybe it should have an option for .xml
- on the importer, there's a Mode type. When importing dynamic VDB's, this shouldn't apply, because the dynamic vdb can have both virtual and source models.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (TEIIDDES-2289) Usability: Add option on VDB editor to deploy VDB
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-2289?page=com.atlassian.jira.plu... ]
Barry LaFond updated TEIIDDES-2289:
-----------------------------------
Fix Version/s: 11.0
(was: 10.0.2)
> Usability: Add option on VDB editor to deploy VDB
> --------------------------------------------------
>
> Key: TEIIDDES-2289
> URL: https://issues.jboss.org/browse/TEIIDDES-2289
> Project: Teiid Designer
> Issue Type: Enhancement
> Components: VDB & Execution
> Affects Versions: 8.5.1
> Reporter: Van Halbert
> Assignee: Barry LaFond
> Priority: Minor
> Fix For: 11.0
>
>
> Since deploying a VDB is what its all about when you're creating the VDB, why not add an option on the VDB editor, so that right after you synch or add models, you can easily deploy the VDB. 3 clicks to deploy every time for something that's done when editing VDB's, should be quick.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (TEIIDDES-2083) VDB datasource creation enhancements
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-2083?page=com.atlassian.jira.plu... ]
Barry LaFond resolved TEIIDDES-2083.
------------------------------------
Fix Version/s: (was: 10.0.2)
Resolution: Won't Do
> VDB datasource creation enhancements
> ------------------------------------
>
> Key: TEIIDDES-2083
> URL: https://issues.jboss.org/browse/TEIIDDES-2083
> Project: Teiid Designer
> Issue Type: Enhancement
> Components: Teiid Integration
> Reporter: Ramesh Reddy
> Assignee: Barry LaFond
>
> 1) When a VDB is deployed, "Create VDB DataSource" dialog pops up, it asks the user whether to create a data source for VDB, but does not provide a "cancel" button to opt out. There should be a "cancel" to opt out.
> * BML - There is a Cancel button on the dialog
> 2) If you are re-deploying the same VDB, the same dialog pops up again asking the same question, it should be changed to honor the previous answer.
> 3) Say if the user did create a data source, then in re-deploy case the data source either needs to be deleted and re-created or flush the connections in the old data source, so that the connections point to valid VDB rather than stale connections.
> 4) It would be even nice, "Remember My Decision" kind of preference, that could always create or not create data source, rather than keep asking the user.
> BTW, this feature is only useful for the Web Service scenarios, so I would start off with OFF position. May be turn it on only ask when web service model in the work space if you want to be fancy. Also detect the name of data source in the web-service war creation scenarios, or let them create with a button right next to it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (TEIIDDES-2050) Full Temp Table support in Designer
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-2050?page=com.atlassian.jira.plu... ]
Barry LaFond updated TEIIDDES-2050:
-----------------------------------
Fix Version/s: 11.0
(was: 10.0.2)
> Full Temp Table support in Designer
> -----------------------------------
>
> Key: TEIIDDES-2050
> URL: https://issues.jboss.org/browse/TEIIDDES-2050
> Project: Teiid Designer
> Issue Type: Feature Request
> Components: Modeling
> Reporter: Barry LaFond
> Assignee: Barry LaFond
> Fix For: 11.0
>
>
> Per TEIIDDES-1794 there are more areas Designer needs to add support for temporary tables:
> ... the full array of temp table stuff we currently support is:
> * Teiid global temporary table (a virtual entry - which from an engine perspective can be on any model type)
> * Teiid temporary table (not a schema entry in the design time metadata, scoped to a session/block)
> * Teiid temporary table backed by a physical table (not a schema entry in the design time metadata, scoped to a session/block - the physical table could be a temporary one)
> Eventually we would also like to have an ease of use path to simply create a teiid temporary table and have the backing table created on a source automatically - similar to the data shipment join temporary table creation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months