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
|
