Translator Deployment in Teiid Jopr Plugin
by Ted Jones
There are two ways to create/deploy resources in Jopr:
1.) Via configuration - where the user enters the configuration values need to create and deploy a resource
2.) As a standalone resource file - think of war or vdb deployment here. The resource archive or file already exists and can be deployed via Jopr.
Any thoughts on which way we should go regarding Translators? If we go with 2, there will be a dependency on the Designer to actually create the Translator resource. If we go with 1, there will be no way to deploy an existing Translator through Jopr (other than manually). There *may* be a way to implement this as a Jopr operation from the Teiid runtime resource but it seems clunky to me to do it this way.
I am pursuing 1 for now due to the Designer dependency, but thought it would be good to air this out in the mailing lists as well in case there is some consideration I have overlooked.
Thanks,
Ted
13 years, 12 months
Re: [teiid-dev] [teiid-designer-dev] Translator Deployment in Teiid Jopr Plugin
by John Doyle
+1, right direction to take for now.
----- "Ted Jones" <tejones(a)redhat.com> wrote:
> There are two ways to create/deploy resources in Jopr:
>
> 1.) Via configuration - where the user enters the configuration values
> need to create and deploy a resource
>
> 2.) As a standalone resource file - think of war or vdb deployment
> here. The resource archive or file already exists and can be deployed
> via Jopr.
>
> Any thoughts on which way we should go regarding Translators? If we go
> with 2, there will be a dependency on the Designer to actually create
> the Translator resource. If we go with 1, there will be no way to
> deploy an existing Translator through Jopr (other than manually).
> There *may* be a way to implement this as a Jopr operation from the
> Teiid runtime resource but it seems clunky to me to do it this way.
>
> I am pursuing 1 for now due to the Designer dependency, but thought it
> would be good to air this out in the mailing lists as well in case
> there is some consideration I have overlooked.
>
> Thanks,
> Ted
> _______________________________________________
> teiid-designer-dev mailing list
> teiid-designer-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
13 years, 12 months
MS 4
by Steven Hawkins
Hello all,
There has been a lot of progress toward M4. The separation of the connector layer is almost complete. We will have JCA resource adapters for file, ldap, salesforce, and webservices (through jax-ws). Webservices should be available shortly, so as soon as tomorrow night's build Ramesh will assess whether M4 is ready.
Package changes
First of all everything is now org.teiid - see TEIID-918. JCA projects use the package convention org.teiid.resource.adapter.<type>. Translators use the convention org.teiid.translator.<type>. Just to clarify, org.teiid.translator classes are responsible for providing a source specific ExecutionFactory and using the language/metadata classes to translate the query/results. Translator was chosen over other terms such as:
connector - potentially confusing with our previous term and JCA
dialect - conflicts with Hibernate, which connotes something specific to a database or other string based query source
execution - conflicts with query.execution
resource.cci - verbose, but consistent with JCA
source - seems generic and passive
Module changes
Translator modules added for jdbc, ldap, loopback, salesforce, text, and yahoo.
connector-text will become connector-file
connector-api will become teiid-api, as it also contains classes related to audit/message logging, JCA, and any other server extension point we'll expose.
This should be the last milestone release before we enter our release candidate phase. Enhancement and api changes need to be addressed in the next couple of weeks or pushed to 7.1. Please update JIRAs as appropriate to clean out the 7.0 bucket.
Steve
14 years
next milestone
by Steven Hawkins
Hello all,
We have made lots of good fixes since MS3 and have made good progress on the next iteration of the connector api. We should target the end of the week for the next milestone. We should have a good handle by then on what exactly will JCA managed connections and built in functionality.
If all looks good, we should move onto a release candidate series with an emphasis on documentation updates.
Steve
14 years
