geesh......... here goes....some random thoughts and questions.... 1) If you are proposing embedding custom Translator XML into vdb.xml , wouldn't that info be worthless unless the JAR file came with it in the VDB? 2) Designer is not intended to be a Translator creator/editor framework. 3) Isn't the CDK providing functionality for creating/editing Translators for custom connectors.....and isn't it the primary tool for maintaining all global "connector" entities specific to Teiid? 4) From a Designer perspective, the user really only sees/knows about Data Source connection info like: driverClass, vendor, version, databaseName, URL, username and password. That's all the info they have, or required to have to import JDBC. 5) Not sure how Designer is moving down the path where "physical model metadata is tied directly to the translator used". We import JDBC metadata and "tweak" some datatypes to match our relational metamodel datatypes, but basically the Relational Source model is a structural representation (with properties) right? If the "translator" properties include items such as xa-capable, immutable, max-results-rows, and execution-factory-class, I don't really see much in the way physical model metadata. I did look at some of your ExecutionFactory classes and I see lots of Database-specific "translation" logic/constants, but none of this gets exposed to Designer, right? 6) (see 5 above) Have no idea what "change your translator == change your physical model" means other than some cheer-leader reference :) 7) .. your statement "... native types, column names, etc., are not the same across all source types." Can you give me an example? ..............not sure what you are expecting Designer to do with these changes? I can see a "dynamic vdb" handling it, but our Relational Source models are instances or views of a specific DB schema (or other data source type). I don't think we have the notion of a "flexible" column name? Barry ----- Original Message ----- From: "Steven Hawkins" <shawkins(a)redhat.com&gt; To: "Van Halbert" <vhalbert(a)redhat.com&gt; Cc: teiid-dev(a)lists.jboss.org Sent: Tuesday, May 25, 2010 1:31:39 PM GMT -06:00 US/Canada Central Subject: Re: [teiid-dev] Translators in the "vdb.xml" file. This is a change toward simple and focused. With the environmental information held by a resource adapter connection factory the remaining properties of a translator are not expected to change. It simplifies deployment greatly to have the vdb be self contained than maintaining translators as another global entity. In any event the deployment of a custom translator is also greatly simplified from before, and should now become as easy as placing the JAR with your ExecutionFactory in the deploy directory. If a custom translator is changed (same name/class, but with different property definitions), then the expectation is that the developer either has considered the impact of the migration, such that the old translators property sets are compatible with the new. If a new name is given and the old custom ExecutionFactory is removed, then a forced migration would occur that requires the change of affected vdbs. I don't necessarily see that as a limitation. We are steadily moving down the path where from dynamic vdb or even designer perspective the physical model metadata is tied directly to the translator used. This is especially true for LDAP and Salesforce, but is even true for JDBC as native types, column names, etc., are not the same across all source types. Only the loopback translator is a jack of all trades, but is of limited usefulness for anything other than basic queries. So to state this a different way, change your translator == change you physical model. ----- Original Message ----- From: "Van Halbert" <vhalbert(a)redhat.com&gt; To: "John Verhaeg" <jverhaeg(a)redhat.com&gt; Cc: teiid-dev(a)lists.jboss.org Sent: Tuesday, May 25, 2010 1:11:14 PM GMT -06:00 US/Canada Central Subject: Re: [teiid-dev] Translators in the "vdb.xml" file. I vote the designer doesn't push the creation of a translator by adding additional translator properties to the vdb.xml file. If the user created a custom connector, they'll already be dealing with the task of deploying it to server(s). Also, if this information is stored in the vdb (call it A) and then if the original custom translator is changed (and replaced) and then vdb "A" is redeployed, don't we now have a usability issue that has to be resolved on whether to replace the existing translator properties or not. Carrying stale information in the vdb has caused us problems in the past, so I would hope we wouldn't head back down that road on the first release. I think this first release should be simple and focused. If the usability in the next release drives it in this direction, then so be it. On May 25, 2010, at 12:39 PM, John Verhaeg wrote: Van Halbert Principal Software Eng. Red Hat, Inc. ------ vhalbert(a)redhat.com _______________________________________________ teiid-dev mailing list teiid-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/teiid-dev _______________________________________________ teiid-dev mailing list teiid-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/teiid-dev