[dna-issues] [JBoss JIRA] Commented: (DNA-37) Federate schema information from relational sources

[ https://jira.jboss.org/jira/browse/DNA-37?page=com.atlassian.jira.plugin.... ] Randall Hauch commented on DNA-37: ---------------------------------- I think we have a couple of choices when it comes to designing the hierarchy for database metadata. 1) Do not use node types at all, but instead use some other mechanism (e.g., hierarchy with predefined names to connote the types of content under it). This would be a difficult approach, as it relies too much on convention and is not flexible (e.g., what happens when a node has multiple types). It also is neglecting several of the primary features of JCR. 2) Use node types, where the node type is used to identify the "primary type" of the node. JCR only allows one primary type, and it is a constant for the lifetime of the node. Other aspects can be captured as mixins and/or property values. The node types and mixins would define the properties and children that are allowed. 3) Use a generic node type (e.g., "nt:unstructured") and do all the interesting things with mixins. Since the node type really allows anything, it doesn't matter that it is constant throughout the node's lifetime. Mixins describing the various facets ("system-ness", "table-ness", "view-ness", "schema-ness" etc.) could be added an removed at will. So if we rule out #1, then the choice is between #2 and #3. Normally, I'd be in favor of #3, but database metadata is fairly structured, and it's usually not important to change from one type to another. The node type could also restrict the types and number of children. Therefore, #2 seems like a better approach to me. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira