[teiid-issues] [JBoss JIRA] (TEIID-5657) VDB Migration Tool

[Steven Hawkins (Jira)]

    [ https://issues.jboss.org/browse/TEIID-5657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13699477#comment-13699477 ] 

Steven Hawkins commented on TEIID-5657:
---------------------------------------

> How do database DBAs handle this? Say if I have PG database 500 tables. I have been thinking FlyDB support, but that is a different issue.

You create separate ddl scripts for given sets of logically related things:
- create schema 1 script
- load data to schema 1 script
- create schema 2 script
- migration schema 1 to next version script
...

It's up to the dba and applications how they divide these things up.  We don't have to worry about the migration steps just yet, which is handled by tools like flydb.  We should however allow for multiple ddl files - especially for legacy customers.  This can be done with an include style statement in the main ddl or by convention in the ddl file names.

> VDB Migration Tool
> ------------------
>
>                 Key: TEIID-5657
>                 URL: https://issues.jboss.org/browse/TEIID-5657
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Documentation, Quick Starts, Tooling
>    Affects Versions: 12.x
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>            Priority: Major
>             Fix For: 12.1
>
>
> A migration tool will be provided to convert customer vdbs into just ddl. More than likely this will be just a single ddl file - which will probably not be acceptable to customers with large vdbs.
> We have this utility already available as just a main method in one of our jars. It is anticipated that a maven repo will be distribution mechanism and minimal documentation will be provided.
> There should be optional validation available for the vdb ddl at build time. This breaks down into 3 parts:
> 1. static syntactic validation, potentially even fully resolving if all metadata is present. This makes sure that basic typos will be caught.
> 2. providing hard errors for things that are completely removed - an error for usage of soap or function models for example.
> 3. providing errors or warning for features that are not yet available - vdb imports, sources that aren't yet supported etc.
> To avoid introducing a new plugin or plugging into fmp it's been suggested that the validation could be run via a generated unit test, which ties into another task which is booster, base project, or last resort an arche type that scaffolds the developer project.
> This could possibly be included in the quickstarts as a means to facilitate its use.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)