[ https://issues.jboss.org/browse/TEIIDDES-1403?page=com.atlassian.jira.plu... ] Barry LaFond updated TEIIDDES-1403: ----------------------------------- Parent: TEIIDDES-1209 Issue Type: Sub-task (was: Feature Request) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIIDDES-1403?page=com.atlassian.jira.plu... ] Barry LaFond commented on TEIIDDES-1403: ---------------------------------------- Have not thought about how we would expose this functionality in Designer. The XML in VDB's would have to be able to expose Metadata/Tables so they could be used in other Transforms? Still not sure how this would/should work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIIDDES-1403?page=com.atlassian.jira.plu... ] Barry LaFond edited comment on TEIIDDES-1403 at 8/6/12 5:01 PM: ---------------------------------------------------------------- Issues include * extracting table/view/column metadata from VDB containing Source and View Models * How does Designer use this metadata in the current Transormation framework * Tracking and injecting VDB imports into workspace VDBs at design-time Possible solution: * Export Metadata (DDL ?) from a VDB and convert to a Foreign Source Model containing some new relational extension data * EXAMPLE: isForeignModel == TRUE , vdbName == "employeesVDB" * Foreign Source Models would have to maintain some original PATH information * Foreign Source Models would have to include actual View/Table/Column UUID's * when that source model is added to a VDB, the vdb import would be created and that Foreign Source model NOT added to VDB was (Author: blafond): Issues include * extracting table/view/column metadata from VDB containing Source and View Models * How does Designer use this metadata in the current Transormation framework * Tracking and injecting VDB imports into workspace VDBs at design-time Possible solution: * Export Metadata (DDL ?) from a VDB and convert to a Foreign Source Model containing some new relational extension data * EXAMPLE: isForeignModel == TRUE , vdbName == "employeesVDB" * when that source model is added to a VDB, the vdb import would be created and that Foreign Source model NOT added to VDB -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIIDDES-1403?page=com.atlassian.jira.plu... ] Barry LaFond commented on TEIIDDES-1403: ---------------------------------------- Seems like the use-case in the description is pretty limited and it also requires Designer to create/manage a new artifact type, "reuse VDB" I would think that users would most likely want to continue to do all modelling in their workspace, including modelling sources and views, creating source and view VDBs and utilizing VDBs as sources (reuse VDBs) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIIDDES-1403?page=com.atlassian.jira.plu... ] Barry LaFond edited comment on TEIIDDES-1403 at 8/9/12 4:07 PM: ---------------------------------------------------------------- Seems like the use-case in the description is pretty limited and it also requires Designer to create/manage a new artifact type, "reuse VDB" I would think that users would most likely want to continue to do all modelling in their workspace, including modelling sources and views, creating source and view VDBs and utilizing VDBs as sources (reuse VDBs) Would also suggest adding a requirement that we expose model visibility as well data role security/info in the solution. Is Teiid equipped in 8.x to handle adhering to the values in the dependent VDBs? was (Author: blafond): Seems like the use-case in the description is pretty limited and it also requires Designer to create/manage a new artifact type, "reuse VDB" I would think that users would most likely want to continue to do all modelling in their workspace, including modelling sources and views, creating source and view VDBs and utilizing VDBs as sources (reuse VDBs) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIIDDES-1403?page=com.atlassian.jira.plu... ] Barry LaFond updated TEIIDDES-1403: ----------------------------------- Description: See https://issues.jboss.org/browse/TEIID-1366, which not only replaces mergeVDB functionality, but provides a declarative way for vdbs to be reused at runtime. Designer will need to provide a representation of the reuse feature that includes: - Optionally an artifact that represents a vdb to import, but that only contains the consumable metadata - _not the transformations_. - A way to manage those imported artifacts in the context of a workspace - A way to edit the imports in the vdb.xml to specify the name/version of what's expected at runtime - preview would be broken unless a deployed version the re-use VDB existed An expected flow should be available from GSS customer requests and at a high-level could be described as: *Scenario A* * Team 1 develops a vdb and exports the "*reuse* *vdb*" _without_ _transformation_ _metadata_ for use by Team 2 * Team 2 develops a new vdb using the reuse vdb - no access is needed to the original vdb *Scenario B* * Team 1 develops a vdb and provides it directly to Team 2 * Team 2 uses original vdb as "source" and models new vdb from it was: See https://issues.jboss.org/browse/TEIID-1366, which not only replaces mergeVDB functionality, but provides a declarative way for vdbs to be reused at runtime. Designer will need to provide a representation of the reuse feature that includes: - Optionally an artifact that represents a vdb to import, but that only contains the consumable metadata - not the transformations. - A way to manage those imported artifacts in the context of a workspace - A way to edit the imports in the vdb.xml to specify the name/version of what's expected at runtime - preview would be broken unless a deployed version the An expected flow should be available from GSS customer requests and at a high-level could be described as: Team 1 develops a vdb and exports the "reuse vdb" without transformation metadata for use by Team 2 or Team 1 develops a vdb and provides it directly to Team 2 Team 2 develops a new vdb using the reuse vdb - no access is needed to the original vdb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIIDDES-1403?page=com.atlassian.jira.plu... ] Barry LaFond commented on TEIIDDES-1403: ---------------------------------------- Based on all the input so far, this will be our initial implementation of VDB Re-use in Designer. 1) Create JDBC Importer option for Teiid-only connections * During import, user can select/deselect schema (models) and tables on Select Database Objects page * Add Check-box for "Import as VDB Source Model" to Specify Import Options page ** Add "description" to note that this is a Teiid VDB import and can be treated in a special way. *** Maybe we default the checkbox to CHECKED? ** if checked, then disable other options *** Make target a view model (DISABLE as UNCHECKED) *** Include catalog for Fully Qualified Names (DISABLE as UNCHECKED) *** Use Fully Qualified Names (DISABLE as CHECKED) **** schema serves as original Model Name and is required for query validation *** Change Case for All Characters (DISABLE as UNCHECKED) 2) Create/Modify JDBC Import Processor * Add VDB name and version as extension data to Model Annotation ** Need to be aware of this new extension data on MS sequencing? * Create VdbSourceModelExtensionHandler class that can peek into ModelResource/IFile and check to see if it's a VDB Source Model as well as inject extension data (See use of ResourceAnnotationHelper class for connection info) 4) VDB Editor changes * Modify VDBModelEntry to look for dependent models, check for 'isVdbSourceModel()" and NOT add index files. ** Add option to "add XMI files" anyway? * Show VDB Source models "differently" ** Show VDB Import as a different VdbModelEntry? (source model icon with yellow VDB on it?) 5) Add any new validation rules 6) Look at potential for circular dependencies? * Create VdbSourceModelAnalyzer * Able to view Tables and table names + VDB name to create a "VDB perspective" of contents? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIIDDES-1403?page=com.atlassian.jira.plu... ] Barry LaFond reassigned TEIIDDES-1403: -------------------------------------- Assignee: Barry LaFond (was: Dan Florian) -- 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