Some comments
(2) The DAS supports passing of a Connection object to the runtime. Our unit tests are obtaining a Connection using DriverManager.
I think the issue is more around this use case in a DAS Container, as the user will not be able to manualy pass a connection as the container would be doing the das instantiation. We might be able to solve this by telling the container that this is a J2SE env on the SCDL. As for :
3) Is it better to follow conventions in forming command name, it can be helpful in Declarative DAS development.
Well, I think we can try to follow one convention, but users can put whatever they want on the das config file... and I also believe this is a valid case... so if they don't follow the convention and there is no other ways to create maps, we would throw back an exceptio... -- Luciano Resende http://people.apache.org/~lresende On 11/22/06, Brent Daniel <[EMAIL PROTECTED]> wrote:
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]
