[teiid-issues] [JBoss JIRA] (TEIID-3260) Create custom metadata repository that uses Modeshape

[Barry LaFond (JIRA)]

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

Barry LaFond edited comment on TEIID-3260 at 2/24/15 11:06 AM:
---------------------------------------------------------------

Fundamentally, the node structure for the *VDB* metadata will be identical for both *library* or *workspace* modes. Only real difference will be in the lock/access restrictions.  How the nodes and properties are actually accessesed and edited is an implementation layer. Designer is designing one version of it for "Design-time". No reason why Teiid Metadata Factory couldn't write their own layer based on your runtime behavior/characteristics.

You'd have to look at our editing layer which involves relational-like objects (Table, Column, Procedure, etc...) that provide convenience methods for getting/setting/adding/removing that delegate to the JCR/MS layer without holding any state information other than the repository PATH string value.  Keeps it light weight.  (Interfaces and Impl's are here:  https://github.com/Teiid-Designer/komodo/tree/master/plugins/org.komodo.relational/src/org/komodo/relational)

The CNDs and sequencers for the VDB, Teiid DDL and SQL components of the VDB artifacts, in theory, should be maintained and kept in sync with BNF and vdb-deployer.xsd schema.  These CND's and corresponding sequencers are the bread and butter of what Modeshape provides.  To date, this work has been by tooling. If you wish to take ownership of those components from a Teiid Project perspective, that'd be great as long as it's exposed, accessible and integratable from the Komodo Tooling perspective.

Btw... the requirement for Komodo Engine to resolve DDL/SQL will inherently support dependency/impact analysis.



was (Author: blafond):
Fundamentally, the node structure for the *VDB* metadata will be identical for both *library* or *workspace* modes. Only real difference will be in the lock/access restrictions.  How the nodes and properties are actually accessesed and edited is an implementation layer. Designer is designing one version of it for "Design-time". No reason why Teiid Metadata Factory couldn't write their own layer based on your runtime behavior/characteristics.

You'd have to look at our editing layer which involves relational-like objects (Table, Column, Procedure, etc...) that provide convenience methods for getting/setting/adding/removing that delegate to the JCR/MS layer without holding any state information other than the repository PATH string value.  Keeps it light weight.  (Interfaces and Impl's are here:  https://github.com/Teiid-Designer/komodo/tree/master/plugins/org.komodo.relational/src/org/komodo/relational)

The CNDs and sequencers for the VDB, Teiid DDL and SQL components of the VDB artifacts, in theory, should be maintained and kept in sync with BNF and vdb-deployer.xsd schema.  These CND's and corresponding sequencers are the bread and butter of what Modeshape provides.  To date, this work has been by tooling. If you wish to take ownership of those components from a Teiid Project perspective, that'd be great as long as it's exposed, accessible and integratable from the Komodo Tooling perspective.



> Create custom metadata repository that uses Modeshape
> -----------------------------------------------------
>
>                 Key: TEIID-3260
>                 URL: https://issues.jboss.org/browse/TEIID-3260
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Server
>    Affects Versions: 8.10
>            Reporter: Van Halbert
>            Assignee: Van Halbert
>
> Create a custom metadata repository implementation that uses ModeShape as the repository for obtaining the VDB metadata for deployment. 



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)