7.0 Dev Plans
by John Doyle
Hey Barry,
In an earlier thread(http://lists.jboss.org/pipermail/teiid-designer-dev/2010-January/0... we talked about integrating the DTP stuff for 7.1. The doc you just put up (http://community.jboss.org/wiki/TeiidDesigner70DevelopmentPlans) says we're going to "Modify DQP/SQL Explorer plugins to execute VDB via DTP's jdbc connection to Teiid." I'd like to clarify what this means.
The work I have done so far with DTP enables a user to do the following in the DTP perspectives.
1) Create connections to Teiid (6.X only for now, but 7.0 should only be minor tweaks because it's just a JDBC connection).
2) View the metadata for the VDB.
3) Use the DTP graphical SQL statement building tools to create queries.
4) Execute SQL statements on the VDB and view results.
I have a suggestion from Steve H that I need to test out that will allow me to integrate the DTP query plan view capability also.
I would like to target the DTP related work to 7.0. Specifically, get rid of the SQL Explorer plugins and execute VDBs via DTPs perspectives. As it is there are a a lot of unknowns in what we're taking on for 7.0, so maybe I'm trying to bite off too much. What do you think?
On a related issue, the DTP code is currently in my private repos, and I was working on an Athena build for it. I thought it would be a good idea to build it as it's own feature so that a non-Designer user of Teiid (someone building a web app on the VDB for instance) could download it without a dependence on Designer, and it could also be built into Designer. To that end I was figuring it could live in the JBTools repos. We can discuss this part on another thread I suppose as its a different issue.
~jd
14 years, 12 months
UDF Related Changes in 7.0 Teiid
by Ramesh Reddy
In Teiid user defined functions (UDF) are defined in a special
"FunctionDefinitions.xmi" file and this file deployed in the Teiid
runtime. Some times there is jar file associated with to provide
implementation classes, and if all the functions are "push down" then it
may not require it.
Lack of name space based functions like per VDB functions, or per
Connector kind of functions were long standing requests from users
(TEIID-231, TEIID-502).
Now in the container environment with its free standing nature this file
causes trouble in terms of deploying a UDF. In 7.0, we going to bundle
this "FunctionDefinitions.xmi" file inside the VDB artifact, such that
each VDB can have its own UDF functions and at the same time solve the
deployment issues.
The tooling in the Designer 7.0 will be modified to include
"FunctionDefinitions.xmi" file in the VDB and Teiid runtime will be
modified to look for the "FunctionDefinitions.xmi" file inside VDB and
deploy it accordingly.
Thanks
Ramesh..
14 years, 12 months
UDF Related Changes in 7.0 Teiid
by Ramesh Reddy
In Teiid user defined functions (UDF) are defined in a special
"FunctionDefinitions.xmi" file and this file deployed in the Teiid
runtime. Some times there is jar file associated with to provide
implementation classes, and if all the functions are "push down" then it
may not require it.
Lack of name space based functions like per VDB functions, or per
Connector kind of functions were long standing requests from users
(TEIID-231, TEIID-502).
Now in the container environment with its free standing nature this file
causes trouble in terms of deploying a UDF. In 7.0, we going to bundle
this "FunctionDefinitions.xmi" file inside the VDB artifact, such that
each VDB can have its own UDF functions and at the same time solve the
deployment issues.
The tooling in the Designer 7.0 will be modified to include
"FunctionDefinitions.xmi" file in the VDB and Teiid runtime will be
modified to look for the "FunctionDefinitions.xmi" file inside VDB and
deploy it accordingly.
Thanks
Ramesh..
14 years, 12 months
7.0 MS 2
by Steven Hawkins
Hello all,
We're looking at getting out MS 2 prior to the JCA merge and release a Designer MS 1 off of MS 2. If you have any pending work that should be committed prior to the milestone, let us know - otherwise we'll release on today or tomorrow.
Steve
15 years
Re: [teiid-designer-dev] Teiid Designer 7.0 Work
by John Doyle
----- "John Verhaeg" <jverhaeg(a)redhat.com> wrote:
> On Jan 26, 2010, at 3:46 PM, Ramesh Reddy wrote:
>
> > On Tue, 2010-01-26 at 15:53 -0500, Barry Lafond wrote:
> >
> >> * Maintain current Preview Data and Execute VDB
> functionality.
> > Unless you are thinking to maintain both Teiid 6.2 along with Teiid
> 7.0
> > in the designer this is not possible.
> >
> > Teiid 7.0 does NOT support embedded version, nor does it work out
> side
> > the container.
> >
>
> No, we're not planning on maintaining 6.2. The idea, which we still
> believe is possible, is to auto-build and deploy VDBs under the covers
> that contain artifacts from the workspace, build an appropriate DTP
> profile, etc., then use DTP's existing preview capability against that
> Teiid source.
>
Does Designer in its current implementation accomplish preview through admin API calls, or some other non-API magic, like writing to the filesystem? If Preview is accomplished via the admin API, then it's just a few lines of code to get a connection to Teiid from DataTools and cast it to a SPECIFIC version of the Admin API that our (non-datatools) plugins could use. This should apply to any admin API provided functionality. Supporting different versions of Teiid in this scenario would require specific code for each Admin API change, which given our current rate of change is understandably every version. I would be in favor of managing this over releases until we slow down, rather than trying to support multiple versions of the engine in a single release of designer. Too complex and we have to much to do.
It is easy however to support viewing metadata and querying a truly DEPLOYED VDB (as opposed to preview) across multiple versions of the Teiid engine. This I do think we should support.
...
> above). Finally, the DTP view that is "given automatically" doesn't
> just show up in Designer automatically - we're still anticipating some
> development work necessary to ensure the user experience remains as
> seamless as possible and to reduce any drastic changes to how things
> work now.
>
Yes, DataTools gives us what we need to view metadata and query, but we will have some work to do to:
1) Deploy
2) Create new connection profile for new VDB.
3) Connect and bring up the DataTools perspective.
I also think we have to do some rebranding. Our perspectives, categories, and plugins get a bit lost when you drop them into a big install like JBoss Tools. We have to be more specific than "Designer".
~jd
15 years
Teiid Designer 7.0 Work
by Barry Lafond
All,
I've been trying to clarify 7.x Teiid Designer goals and tasks.....and here's my starting point for discussion:
Release 7.0 - Target Date: March, 2010
Primary goal: make changes necessary to maintain compatibility with Teiid 7.0 release and in particular, JCA-related changes. Tasks will include:
• Inherit miscellaneous code no-longer needed by Teiid, but still used within Designer ( completed )
• Changes to connector/driver framework required to accommodate JCA changes within Teiid relating to VDB packaging and execution.
• Maintain current Preview Data and Execute VDB functionality.
Release 7.1 - Target Date: June, 2010
Primary Goal: Simplify integration with Eclipse tooling and reduce code-base by replacing functionality by utilizing available/existing open source work, in particular, DTP and it's Data Source and Connector Profile frameworks and reduce or remove dependency on embedded Teiid.
• Change Designer's JDBC import to utilize Eclipse's DTP data sources and connection profiles.
• Replace Designer's SQL Explorer (and possibly Preview Data) functionality via VDB-to-server deployment and DTP query execution.
Barry LaFond
Teiid Designer Project
15 years
Teiid Designer 6.3 hurdles
by Barry Lafond
All,
Thanks to Dan Florian and John Verhaeg for tackling and solving the EMF resource problems we were encountering.
I've also located our performance bottleneck trying to use Eclipse 3.5 & Teiid Designer.
Our "debug" framework was utilizing a method in Eclipse's osgi bundle framework that wasn't a problem in 3.4.1, but is now a "dog" in 3.5.0. Fortunately, Designer's trace/debug framework that we developed a LONG time ago isn't even exposed in Teiid Designer and was targeted for removal at some point.
We'll just prevent the code from getting that far and we should be good to go.
So we'll be moving ahead to a little heavier testing here in the next day or so and hopefully have 6.3 released by Monday, Jan. 18th.
Barry LaFond
Teiid Designer Project Lead
15 years
