[teiid-issues] [JBoss JIRA] (TEIID-4121) Enhancing the External Materialization

[Steven Hawkins (JIRA)]

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

Steven Hawkins commented on TEIID-4121:
---------------------------------------

> but currently, one VDB may have multiple "status" table, each view may have it's own "status" table.

The primary reason for this is that we do not claim ownership of external materialization and the status table - where ever it is convenient for the vdb developer to locate the status, that's where it should be placed.  If the vdb developer chooses to point all of the materializations at the same status table that is up to them.  What you are probably wanting here is some kind of vdb global or default option.  As Ramesh says though to keep our logic consistent it still needs to be exposed to use as a source.

> But we lack the validation in metadata loading, in my previous test, the Internal Mat view configured lots of external view's properties like "status" table, the validation not throw excepton.

We don't need to throw an exception if extra properties are used - at worst that would be a warning.  There are other circumstances though that do warrant validation that is not currently done - see TEIID-3999


> Enhancing the External Materialization
> --------------------------------------
>
>                 Key: TEIID-4121
>                 URL: https://issues.jboss.org/browse/TEIID-4121
>             Project: Teiid
>          Issue Type: Sub-task
>          Components: Query Engine
>    Affects Versions: 9.x
>            Reporter: Kylin Soong
>            Assignee: Steven Hawkins
>             Fix For: 9.0
>
>
> The intention of move "status" table to physical database is to increase durable and fully control refresh and loading, but it increase the complexity.
> The "status" table by design should unique for whole VDB, if you look the https://teiid.gitbooks.io/documents/content/caching/External_Materialization.html#_usage_steps, the table structure:
> {code:sql}
> CREATE TABLE status
> (
>   VDBName varchar(50) not null,
>   VDBVersion integer not null,
>   SchemaName varchar(50) not null,
>   Name varchar(256) not null,
>   TargetSchemaName varchar(50),
>   TargetName varchar(256) not null,
>   Valid boolean not null,
>   LoadState varchar(25) not null,
>   Cardinality long,
>   Updated timestamp not null,
>   LoadNumber long not null,
>   PRIMARY KEY (VDBName, VDBVersion, SchemaName, Name)
> );
> {code}
> but currently, one VDB may have multiple "status" table, each view may have it's own "status" table. Further more, we can consider create status table automatically, which like internal, status create once VDB start, and configured in VDB scope.
> From finishedDeployment logic in MaterializationManager, MATERIALIZED_TABLE be used to determine whether the Mat is internal or external, But we lack the validation in metadata loading, in my previous test, the Internal Mat view configured lots of external view's properties like "status" table, the validation not throw excepton.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)