Scott,
For (a) please file a Bugzilla against
BIRT with an explanation of the problem and any possible code contribution. I’d
be happy to look into the possibility of inclusion in 2.3.
For (c), we plan to deprecate the BIRT SQL
query editor in favor of integrating the SQL query builder from the Datatools (DTP)
project (see Bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=204344).
We therefore do not plan any feature updates to the current jdbc UI.
There is certainly value in supporting a vendor-specific
SQL translation, although I think a better approach is to take advantage of DTP’s
SQL query model framework, which supports a generic SQL query model and vendor-specific
syntaxes through extensions. We have plans to use the DTP query model in the
next BIRT release to support features related to SQL manipulation. That will
also be a good time for us to address features related to syntax translation. We’d
certainly love to have you bring in your expertise in this area. Again the best
place to start is with Bugzilla enhancements to discuss specific use cases that
you’d like to address, and we can carry our discussion there.
thanks,
Gary Xue
From: birt-pmc-bounces@xxxxxxxxxxx
[mailto:birt-pmc-bounces@xxxxxxxxxxx] On
Behalf Of Scott Rosenbaum
Sent: Monday, April 07, 2008 9:25
AM
To: BIRT PMC communications
(including coordination, announcements,and Group discussions)
Cc: birt-pmc-bounces@xxxxxxxxxxx;
Steve Schafer
Subject: Re: [birt-pmc] ODA
Updates
Mike,
I think that 'a' could make it into 2.3 very easily, and should. It definitely
has the most bang for the buck. I think that 'c' is the most dependent on
changes in DTP for 2.3. We (Steve and I) have to spend some more time
with 2.3 to evaluate the scope of the change against 2.3.
Your concerns on option b are on track. What we have developed uses a
properties file where the user can specify replacement pairs, using either
regex or straight replacement to convert from one dialect to another.
Coming up with a full solution will require quite a bit more work. The
question to me is if BIRT should try to 'solve' the issue or provide a
mechanism that allows implementers to solve on an as needed basis. I
think the best approach would be to provide a core solution, that can be easily
extended by implementers to their unique constraints.
Scott
Michael Fox wrote:
HI Scott,
I
believe there is no meeting today. I had that in my notes from last week,
and had deleted the meeting from my calendar.
Regarding
your proposed enhancements below, "a" and "c" look good,
but I'm concerned about the SQL dialect translation. There are subtleties that
make a general solution very difficult, especially for long complex queries. This
may be a better approach to put in the tool because it is template based and
the developer has to specify rules. I'd like to get more details though. I'd
be hesitant to claim that we can generically translate between dialects.
I
presume that you are not intending this work for V2.3?
Mike
Are we having a PMC today, I seem to remember that we are deferring this
weeks activities.
In any case, I have an issue that I want to run by the PMC. One of my
consultants has been working with the jdbc ODA and has a series of enhancements
that we would like to make to the existing jdbc ODA. The list of
enhancements are:
a) Support for Named Parameters.
The jdbc specification does not provide support for named parameters out of the
box. Steve has created a relatively simple substitution system that
converts named parameters into simple parameters. We have actually used
this system at a client and it worked very well. I believe that this
would really make the jdbc ODA more functional.
b) Support for SQL Dialects
There are basic differences between the many SQL dialects. For example
Oracle uses NVL, TransactSql uses IsNull. Steve has created a property
template that allows a developer to specify substitution rules which will
translate between SQL dialects. This means that the same sql query can be
used against multiple sql servers and still support the subtle differences in
the SQL dialects.
c) Re-Factor jdbc UI
There are several methods in the oda.jdbc.ui that access the java.sql.* classes
directly as opposed to using the oda.jdbc runtime classes. When this
happens it makes it difficult for someone to extend the oda.jdbc runtime only,
which should be relatively straight-forward. Instead the user has to
modify both the oda.jdbc and the oda.jdbc.ui packages.
Wanted to know the best way to handle this. Should it be done as one
bugzilla entry with code submissions attached to it? Should it be done as
three (or more) bugzilla entries? Should it be done as a sub-project
proposal?
We can probably handle this through email if we are not having PMC today.
Thanks,
Scott _______________________________________________
birt-pmc mailing list
birt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/birt-pmc
_______________________________________________
birt-pmc mailing list
birt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/birt-pmc
