[ https://jira.jboss.org/browse/TEIID-1328?page=com.atlassian.jira.plugin.s... ] Steven Hawkins commented on TEIID-1328: --------------------------------------- We've been contemplating this on our long term road map for a while. SQL/MED with some Teiid specific extensions would provide a mechanism for DDL based definition of translators/foreign schemas or tables. While updates to a dynamic vdb deployment file can approximate VDB updates, it's less than ideal (triggers a full redeployment, requires a full write out of the file, needs alternative deployment path to update all nodes a cluster, etc.). We may want to have an operational repository that acts more like traditional database before baking this functionality directly into Teiid. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/TEIID-1328?page=com.atlassian.jira.plugin.s... ] Ramesh Reddy commented on TEIID-1328: ------------------------------------- There are two different features in here as I see it, 1) Adding and removing the data sources. 2) View definition for the model itself. So, user issues SQL/MED DDL statements, which are converted to equivalent concepts in a operational store, which is then used as metadata repo for Teiid that represents a VDB. If this is true, aren't we defining two different mechanisms to define the metadata? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1328?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-1328: ---------------------------------- Unassigning. No progress has been made and the issue has not be targeted to a specific release. This will be a candidate for a deferred resolution if no updates occur. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1328?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1328: --------------------------------------- The remaining issue here is whether/how to support adding/removing source metadata. The JCA datasource is easily added via admin api, but currently the closest we come for metadata is redeploying an updated dynamic vdb. Mark to clarify are you requesting: - to add/remove source models to a live, possibly non-dyamic, vdb - and expect the effects of the add/remove to be persistent This is a thornier issue also if view layers are involved as we have to do more work to ensure view integrity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1328?page=com.atlassian.jira.plugin... ] Mark Addleman edited comment on TEIID-1328 at 1/20/12 2:35 PM: --------------------------------------------------------------- Sorry, just saw this. To clarify our use case: we have data sources that come and go. We know when these events occur and could programatically trigger a redeploy using the admin API. The only real problem with this approach is that it causes every metadata to be reloaded from every model. For some of our models, this is prohibitively expensive. As I see it, there are a couple of possible solutions: (1) as Steve points out above, we could add/remove source models to VDB (we only care about dynamic VDBs) (2) a special redeploy mechanism indicating that certain source models can re-use previous metadata was (Author: markaddleman): Sorry, just saw this. To clarify our use case: we have data sources that come and go. To support this, we We know when these events occur and could programatically trigger a redeploy using the admin API. The only real problem with this approach is that it causes every metadata to be reloaded from every model. For some of our models, this is prohibitively expensive. As I see it, there are a couple of possible solutions: (1) as Steve points out above, we could add/remove source models to VDB (we only care about dynamic VDBs) (2) a special redeploy mechanism indicating that certain source models can re-use previous metadata -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1328?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-1328: ------------------------------------- Taking your last comment little further, do not use "useConnectorMetadata", then manage the caching of metadata entirely in translator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1328?page=com.atlassian.jira.plugin... ] Mark Addleman commented on TEIID-1328: -------------------------------------- I like the idea of controlling the caching at the translator level. It sounds like that's a matter of setting useConnectorMetadata=false in the VDB and adding a bit of caching logic. For a couple of reasons, I'm planning on using a delegating translator to wrap all of our real translators so it make sense to centralize the caching logic there. Could I simply cache the MetadataFactory as returned by the underlying translator? On VDB reload, the cache logic would return the cached MetadataFactory? It almost seems too easy... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1328?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1328: --------------------------------------- Do not set useConnectorMetadata=false that indicates that the source is not dynamic. If you are performing your own caching, you will still need useConnectorMetadata=true. MetadataStore is serializable, which is what the engine stores. However, with the current translator metadata method signature and MetadataFactory methods it isn't straight-forward to simply return a saved MetadataStore/MetadataFactory. We'll evaluate if making changes to those classes is the right approach. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1328?page=com.atlassian.jira.plugin... ] Mark Addleman commented on TEIID-1328: -------------------------------------- (for some reason, I never receive notifications from jira) The combination of getMetadataStore/setMetadataStore seems like it will do the trick. One question comes to mind: in our caching case, how best to associate some cached metadata with a particular translator/connection pair? I guess we could construct our VDB in a manner to ensure that every pair has a unique translator property but I'm hoping for a less radical solution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1328?page=com.atlassian.jira.plugin... ] Mark Addleman commented on TEIID-1328: -------------------------------------- Here's want I want to do: 1) A delegate translator caches the results of the delegate's getMetadata call by serializing the metadata store to disk 2) On VDB reload, the delegate translator provides the cached results using setMetadataStore instead of delegating the getMetadata call The question is, what is the key I should use to name the serialized metadata store so that the delegating translator can provide the proper data in step 2? Now, having gone through the code a little deeper, it looks like MetadataStore is a singleton and not per translator as I originally assumed. Is this correct? If so, it seems like we could cache the entire store in one operation and, on VDB reload, call setMetadataStore with the deserialized singleton on each getMetadata call. A little hacky, but effective. Alternatively, I think we could be more individualistic by using the schema name as a key to identify each individual connection/translator pair. If that's the case, it would be convenient if you provided a public getSchema() method in the MetadataFactory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1328?page=com.atlassian.jira.plugin... ] Mark Addleman commented on TEIID-1328: -------------------------------------- Thanks, Ramesh. It sounds like, under 8.0, I can do exactly what I want. I haven't examined the code yet but will in the upcoming week. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira