Affects: Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial Workaround Description: To work around this error - the user must: 1. Stop the server 2. Delete the teiid cache (server/profile/ 3. Perform steps 1-4 - in the order listed above. The problem and workaround seem to be 100% reproducible. project_key: SOA If the user executes the example's steps in the order - then the example runs successfully: 1. Start the server 2. Create the DB tables 3. Deploy the .vdb file 4. At this point - this command returns the expected rows: ./run.sh localhost 31000 dynamicportfolio "select * from product" But - if the user performs step #3 first, then the query performed in step #4 fails with an error of: Caused by: [TeiidProcessingException]Remote org.teiid.api.exception.query.QueryResolverException: Group does not exist: product
This isn't just a problem with the example, this could happen anytime a dynamic vdb is being used in this type of scenario.
Just to be clear, if you perform things in the sequence of 3, 1, 2, 4 and the database tables are created after the server is started and the .vdb file is deployed then you are seeing expected behavior. Teiid does not automatically detect / resolve metadata changes for a given vdb name/version.
Other than deleting the teiid cache - and restarting the server - what's the best/easiest course of action for a user to clear up this situation?
https://issues.jboss.org/browse/TEIID-1329 is a feature request to programatically trigger metadata loads for dynamic vdbs. However it's a little more complicated than it seems due to the way we hold the metadata structures internally. Changes to the metadata currently require a new vdb version or something that looks like a redeploy action so that connections using old metadata are dropped. Other workaround are: you can redeploy with just be an overwrite of the .vdb file, or increment the version number, or set UseConnectorMetadata to true rather than cached which will trigger a reload every time the vdb is loaded without having to delete cache files.
Therefore, should all the dynamic vdb's in the examples have UseConnectorMetadata=true
I wouldn't come to that conclusion. There is only an issue if you have a different expectation of the dynamic vdb feature than what it actually does. And setting the value to true will still require a restart or redeploy of the vdb. It would be simpler to just expect people to follow the sequence of steps in the readme or add more verbage to the reference on metadata loading (actually its already covered pretty well, perhaps you'd be looking for a warning or note call out). You could also add another example with the purpose of demonstrating the reload of metadata.
And...we need to describe the current operation of the dynamic VDBs for users - is this accurate? A dynamic VDB has its virtual database metadata loaded when the VDB is deployed. As a result, it is possible to create a situation where a dynamic VDB may not be able to fully access its backing database tables. For example, if a VDB accesses tables in a backing database, and the VDB is deployed to a server before the backing database tables are created, then the VDB's metadata will not automatically be reloaded. The proper sequence for using dynamic VDBs is to create any backing database tables before deploying a VDB that relies on those tables.
Link: Added: This issue related SOA-2844
Workaround Description: Removed: To work around this error - the user must: 1. Stop the server 2. Delete the teiid cache (server/profile/ 3. Perform steps 1-4 - in the order listed above. The problem and workaround seem to be 100% reproducible. Added: To work around this error - the user must: 1. Stop the server 2. Delete the teiid cache (server/profile/ 3. Perform steps 1-4 - in the order listed above. The problem and workaround seem to be 100% reproducible.
Link: Added: This issue is a dependency of TEIID-1470
Writer: Added: Darrin
The GSG also mentions this in one of the examples.
Release Notes Docs Status: Added: Documented as Known Issue Release Notes Text: Added: Dynamic VDBs capture source meta-data when they are deployed. Dynamic VDBs without meta-data caching enabled also do this at every time the server starts. However the captured meta-data will be invalid if the referenced data sources are not available when the dynamic VDB is deployed or if the metadata changes afterwards. This can be fixed by redeploying the dynamic VDB. This will also be fixed in a non-caching dynamic VDB by restarting the server.
The sequence of loading vdb metadata has been documented and an enhancement (SOA-2844) has been created to provide reloading of the metadata.