VIEWS removed

[virtualdatabase]

I've recently noticed there are no longer object types of VIEW in designer I'n not sure when exactly it happened but I've only now been impacted.  When an enterprise has a metadata managment solution quite often such systems crawl databases to discover 'what's there and provide data-lineage.  Given there are no VIEW types there is also no access to the "view definition" and therefore data lineage cannot be 'discovered'.

Is there another solution to acheive such that I am not aware or thinking of?

Thanks!

[rareddy]

Previously there were VIEW Table and BaseTable constructs for the View model. Essentially there was nothing different between these two table types, so they got merged into single "Table.." type. When you create a table in view model, you get presented with way to provide the transformation, where as on source model it represents a physical table in the source database/system.

Ramesh..

[virtualdatabase]

I'm speaking at runtime... there is a significant difference in the relational metamodel between a table and a view.  Also, from a data lineage perspective it's somewhat implied that there will likely been dependent objects to a 'view' and is discovered through its viewsource.  So without access to the transformation at runtime that lineage is not possible.

[rareddy]

Were u asserting that that information was previously available and it is not now? AFAIK, this was never available to the user in Teiid.

The metadata information in Teiid is either available in the SYS tables, or you need to use ModeShape based solutions. When you use ModeShape a VDB can be sequenced and the transformation definitions can be retrieved from its repositories using JCR API or REST etc.

Ramesh..

[shawkins]

To clarify a couple of things, as Ramesh says Designer intends for a Teiid view to be a table entry on a virtual model.  Then what you may be getting at from a runtime perspective is [TEIID-2754] DatabaseMetaData reports views as tables - JBoss Issue Tracker

I'd have to look back further, but I believe the Designer change highlighted that the DatabaseMetaData never considered what a virtual table would be reported as.  So now there's a property, although we may default it to true in a later release, to report virtual tables as views.

> So without access to the transformation at runtime that lineage is not possible.

That is yet another concern.  Who or what is accessing the transformation and parsing/resolving to determine lineage?

[virtualdatabase]

The reference you made to [TEIID-2754] DatabaseMetaData reports views as tables - JBoss Issue Tracker was useful as it shows the reportAsViews property that I was unaware of, however, as Ramesh also pointed out the 2nd underlying issue is that the transformations are not visible so to your question tools that crawl databases for metadata (metadata managment tooling etc) need to know when an object is a view (so your reference to reportAsViews helps with that) but the fact that we do not expose the transformation through any of the system tables or jdbc databasemetadata() methods would prevent these tools to 'discover' the information needed to create their own internal data-lineage reporting..

[van.halbert]

There was a reason, in Designer, for creating a Base Table versus a View.  And that was the ability to create keys.  User's wanted the metadata, so we instructed them to use Base Table, because a View didn't allow keys to be created.

[shawkins]

> but the fact that we do not expose the transformation through any of the system tables or jdbc databasemetadata() methods

There is no standard place for view / procedure definitions in JDBC DatabaseMetaData.  There is the admin GetSchema method that reports DDL from VDBs.  You could ask down to an individual view/procedure.  But yes, it is correct that we don't yet expose the definitions in a system table.