Amita, (1) I have done some testing with oracle on my own, but have not checked anything into Tuscany for a couple of reasons. First, the DAS makes very heavy use of JDBC ResultSetMetaData. Unfortunately, Oracle's JDBC drivers return a null or empty value for ResultSetMetaData.getTableName(). They have an open issue for this, but, as far as I know, have no plans to fix it. There are some drivers from DataDirect that solve this problem, but I don't have access to them. The DAS was designed to support this case, but it requires users to provide a ResultSetShape in the Config. Unfortunately, other than the tests designed to test ResultSetShape, most of our unit tests would fail on Oracle.
In addition to this issue, I would like to see the DAS focus on a small number of vendors at first until most of the planned function is implemented. This allows us to focus on the DAS rather than chasing down vendor-specific issues. Having said that, any contributions to the DAS to support vendors other than Derby and MySQL would be welcome. :) (2) The DAS supports passing of a Connection object to the runtime. Our unit tests are obtaining a Connection using DriverManager. (3) I havn't thought about this, but sounds like a good idea. (4) My feeling is that the DAS exists to enable SDO rather than to be a general persistence layer. (5) I agree -- ideally we would like to have a DAS api that can access multiple back ends. Brent On 11/22/06, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
Hi, I am trying to understand DAS for last couple of weeks and thought that below may be helpful to make DAS more generic. 1) Oracle database support? - Are we not going to consider this 2) Support for working with J2SE - connection support - this way standalone applications can also benefit from DAS 3) Is it better to follow conventions in forming command name, it can be helpful in Declarative DAS development. 4) Some abstraction layer provided by DAS to shield the usage of SDO. So behind the curtain, DAS can be flexible between using SDO or another data representation. 5) Same thing applies to RDB, non-RDB. So, the SCA-DAS integration effort can be based on these abstractions instead of dealing with SDO, RDB directly. Regards, Amita On 11/22/06, Brent Daniel <[EMAIL PROTECTED]> wrote: > > Hey Luciano, > > A few updates.. I committed some changes to the MySQL test suite > yesterday to solve the problems with the dog kennel tests and one of > the stored procedure tests (Sorry, I didn't realize there was a JIRA > for it.) Things should run fine now. The default OCC policy has been > in for a while now (I don't think it made M2 but is in the trunk.) I > hope to put in OCC recovery support this week while I have some time > to work on it. > > Thanks, > Brent > > On 11/21/06, Luciano Resende <[EMAIL PROTECTED]> wrote: > > With the M2 release out, I'd like to look forward to things that we want > to > > do next for DAS. > > > > I think that there are still couple things that we can improve our core > DAS > > features, like improving our Optimistic Concurrency Control support, > improve > > the performance of our pager api and review our MySQL support as I have > > noticed some test failures recently. > > > > As for our history with SCA integration, we have started efforts around > > Declarative DAS, and this is probably another area we would like to > continue > > to work going forward. This effort would probably also contribute to our > > samples, as I'd assume we would create some simple samples consuming > these > > new ways of using DAS. > > > > I also think we should continue to improve our user documentation and > > distribution infrastructure to make our release cut easier. > > > > Below is a summary list of items and JIRAs that are related to these > > possible items : > > > > DAS Core features'' > > - Optimisc concurrency control > > - Support for OCC recovery (TUSCANY-916) > > - Default OCC policy (all OCC-capable fileds used in overquaified > > "where") > > - More performant pager (TUSCANY-542) > > - Review MySQL Support (TUSCANY-937) > > > > - SCA Intgration > > - Expose DAS as a Pojo SCA Service (impl.java) (TUSCANY-898) > > - Container-based DAS (impl.das) (TUSCANY-904) > > > > DAS Samples > > - Sample consuming DAS as a Pojo SCA service > > - Sample consuming container-based DAS > > > > Documentation > > - Continue to work on DAS User's guide > > - HOW-TO describing how to build a DAS Application > > > > Infrastructure > > - Automate release distribution process > > > > > > This is just of brain dump of where my thinking is at the moment, I'm > sure > > everyone has their own thoughts about things we should tackle. > > It would be good to get to them all on the table :-) > > > > > > -- > > Luciano Resende > > http://people.apache.org/~lresende > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
