You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2006/11/21 20:55:51 UTC
What's next for Tuscany DAS ?
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
Re: What's next for Tuscany DAS ?
Posted by Kevin Williams <ke...@qwest.net>.
Luciano Resende wrote:
> 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.
At one point, we intended to support both the DataSource info (as we
have today for J2EE applications) as well as DriverManager info for J2SE
applications. We may have rejected the idea early on because of the
need to put username/password info in the config for DriverManager.
I have opened TUSCANY-948 to track this.
>
> 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...
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What's next for Tuscany DAS ?
Posted by Luciano Resende <lu...@gmail.com>.
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 <br...@gmail.com> 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 <am...@gmail.com> 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 <br...@gmail.com> 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 <lu...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: What's next for Tuscany DAS ?
Posted by Brent Daniel <br...@gmail.com>.
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 <am...@gmail.com> 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 <br...@gmail.com> 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 <lu...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What's next for Tuscany DAS ?
Posted by Amita Vadhavkar <am...@gmail.com>.
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 <br...@gmail.com> 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 <lu...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: What's next for Tuscany DAS ?
Posted by Brent Daniel <br...@gmail.com>.
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 <lu...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What's next for Tuscany DAS ?
Posted by Kevin Williams <ke...@qwest.net>.
A couple of ideas around samples:
A sample that demos well and illustrates our major capabilities:
OCC + recovery, Generated ID, write-operation ordering, Converters,
aliases, integration with SCA, etc.
A sample that can be constructed during a presentation
Regarding the Paging capability:
I think there are really two areas that need attention. Performance
definitely needs to be looked at but we also need a truly
"disconnected" pager. T-542 tracks this issue.
Thanks.
--
Kevin
Luciano Resende 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 :-)
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org