Re: Tuscany DAS Features/Questions

[Amita Vadhavkar <am...@gmail.com>]

It will be interesting to get these features into DAS using JIRAs.
I am just trying to get a clear picture of what all details these features
can consist.

1. This can be support for explicit as well as SDO-integrated
inserts/updates

2. a. Here validations can be based on Database provided Meta Data, also,
we can think of defining custom validations per Command basis in DAS
config. What do you think?

2. b. As part of {2. c. 2>} , This will have more control on individual
DataGraphs contained
in the root Data Graph. With this, invalid (validation failed) Data Graphs
can be
deleted from the tree. The dependency management logic will need to handle
the consequent
actions for this deletion(parent-child etc.).
2. c. There can be 2 situations -
1> when the data graphs are not of related database entities, here different
config files can split the work
2> when they are for related entities, the worker threads will be sharing
part of load
of same transaction.

Please add your thoughts and any more desirable but missing features, that
DAS can
take up.

Regards,
Amita


On 5/15/07, Luciano Resende <lu...@gmail.com> wrote:
>
> Should we start creating some JIRAs for these enhancement requests ?
>
> On 5/14/07, Brent Daniel <br...@gmail.com> wrote:
> >
> > 1. Not today, though I think this would be a good feature for the DAS
> > to pick up.
> >
> > 2 a. No, but that would be an interesting capability. Today I think
> > validation would best be performed at the client level.
> >
> > b. It's probably easiest to do this on a case by case basis..
> > Unfortunately I don't think there's an easy way to undo individual
> > changes (though you can always undo everything using
> > ChangeSummary.undoChanges()).  To undo an insert, you can simply
> > delete the DataObject. For property changes, you can use
> > changeSummary.getOldValues() to get the previous values and re-set
> > them. I'm not sure if anything easier is coming in future versions of
> > SDO or not.
> >
> > c. The DAS has some paging capability for situations like this. From
> > your description of your application, it sounds like you may also be
> > able to simply break the app down so that you use several different
> > config files with independent DataGraphs.
> >
> > Brent
> >
> >
> > On 5/11/07, Ron Gavlin <rg...@yahoo.com> wrote:
> > > Greetings,
> > >
> > > We are considering replacing some of our custom, home-grown DAS' with
> > Tuscany DAS. As a result, I have a few Tuscany DAS questions.
> > >
> > > 1. Does the Tuscany DAS have any support for JDBC Batch Update/Insert
> > operations?
> > >
> > > 2. I have a multi-tiered application in which I send a DataGraph of
> > DataObjects from the middle-tier to a client and later receive the
> updated
> > DataGraph from that client. I would like to apply validation to some of
> the
> > DataObjects in the DataGraph before the changes are persisted to the
> > database.
> > >
> > >    a. Is there a mechanism for integrating my validation into the DAS'
> > applyChanges() operation to avoid the overhead of traversing the
> > ChangeSummary twice, once by me and once by the DAS?
> > >
> > >    b. When a single DataObject fails validation, what is the best way
> > for me to undo the changes to that particular DataObject so the DAS
> ignores
> > just those changes and doesn't persist them to the database?
> > >
> > >    c. The DataGraph of changed DataObjects if often large in my
> > application. Also, my custom validation logic is quite expensive. So, I
> > would like to break the DataGraph into multiple "sub-DataGraphs" and
> execute
> > the validation logic and the DAS' applyChanges() on separate WorkManager
> > threads. I am doing something like that today with my own home-grown DAS
> > that is custom to my trivial data model, whereby the DataGraph is simply
> a
> > container for a list of DataObjects that map one-to-one to a database
> table.
> > >
> > > Thanks in advance for your assistance/insights,
> > >
> > > - Ron
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
>

Re: Tuscany DAS Features/Questions

[ant elder <an...@gmail.com>]

How about DAS-Next as thats what we've talked about using as the name for
the next release of all the other Tuscany projects? (I've just renamed
DAS-Mx to DAS-Next in JIRA).

   ...ant

ps, you don't need to be asking to create a jira, just do it if you think it
helps.

On 5/23/07, Amita Vadhavkar <am...@gmail.com> wrote:
>
> Hi Folks,
> Can I create JIRAs for these and mark them for DAS Mx, just to have a
> pointer to come back to these features?
> Regards,
> Amita
>
> On 5/15/07, Amita Vadhavkar <am...@gmail.com> wrote:
> >
> > It will be interesting to get these features into DAS using JIRAs.
> > I am just trying to get a clear picture of what all details these
> features
> > can consist.
> >
> > 1. This can be support for explicit as well as SDO-integrated
> > inserts/updates
> >
> > 2. a. Here validations can be based on Database provided Meta Data,
> also,
> > we can think of defining custom validations per Command basis in DAS
> > config. What do you think?
> >
> > 2. b. As part of {2. c. 2>} , This will have more control on individual
> > DataGraphs contained
> > in the root Data Graph. With this, invalid (validation failed) Data
> Graphs
> > can be
> > deleted from the tree. The dependency management logic will need to
> handle
> > the consequent
> > actions for this deletion(parent-child etc.).
> > 2. c. There can be 2 situations -
> > 1> when the data graphs are not of related database entities, here
> > different config files can split the work
> > 2> when they are for related entities, the worker threads will be
> sharing
> > part of load
> > of same transaction.
> >
> > Please add your thoughts and any more desirable but missing features,
> that
> > DAS can
> > take up.
> >
> > Regards,
> > Amita
> >
> >
> >  On 5/15/07, Luciano Resende <lu...@gmail.com> wrote:
> > >
> > > Should we start creating some JIRAs for these enhancement requests ?
> > >
> > > On 5/14/07, Brent Daniel < brenthdaniel@gmail.com> wrote:
> > > >
> > > > 1. Not today, though I think this would be a good feature for the
> DAS
> > > > to pick up.
> > > >
> > > > 2 a. No, but that would be an interesting capability. Today I think
> > > > validation would best be performed at the client level.
> > > >
> > > > b. It's probably easiest to do this on a case by case basis..
> > > > Unfortunately I don't think there's an easy way to undo individual
> > > > changes (though you can always undo everything using
> > > > ChangeSummary.undoChanges()).  To undo an insert, you can simply
> > > > delete the DataObject. For property changes, you can use
> > > > changeSummary.getOldValues () to get the previous values and re-set
> > > > them. I'm not sure if anything easier is coming in future versions
> of
> > > > SDO or not.
> > > >
> > > > c. The DAS has some paging capability for situations like this. From
> > > > your description of your application, it sounds like you may also be
> > > > able to simply break the app down so that you use several different
> > > > config files with independent DataGraphs.
> > > >
> > > > Brent
> > > >
> > > >
> > > > On 5/11/07, Ron Gavlin <rg...@yahoo.com> wrote:
> > > > > Greetings,
> > > > >
> > > > > We are considering replacing some of our custom, home-grown DAS'
> > > with
> > > > Tuscany DAS. As a result, I have a few Tuscany DAS questions.
> > > > >
> > > > > 1. Does the Tuscany DAS have any support for JDBC Batch
> > > Update/Insert
> > > > operations?
> > > > >
> > > > > 2. I have a multi-tiered application in which I send a DataGraph
> of
> > > > DataObjects from the middle-tier to a client and later receive the
> > > updated
> > > > DataGraph from that client. I would like to apply validation to some
> > > of the
> > > > DataObjects in the DataGraph before the changes are persisted to the
> > > > database.
> > > > >
> > > > >    a. Is there a mechanism for integrating my validation into the
> > > DAS'
> > > > applyChanges() operation to avoid the overhead of traversing the
> > > > ChangeSummary twice, once by me and once by the DAS?
> > > > >
> > > > >    b. When a single DataObject fails validation, what is the best
> > > way
> > > > for me to undo the changes to that particular DataObject so the DAS
> > > ignores
> > > > just those changes and doesn't persist them to the database?
> > > > >
> > > > >    c. The DataGraph of changed DataObjects if often large in my
> > > > application. Also, my custom validation logic is quite expensive.
> So,
> > > I
> > > > would like to break the DataGraph into multiple "sub-DataGraphs" and
> > > execute
> > > > the validation logic and the DAS' applyChanges() on separate
> > > WorkManager
> > > > threads. I am doing something like that today with my own home-grown
> > > DAS
> > > > that is custom to my trivial data model, whereby the DataGraph is
> > > simply a
> > > > container for a list of DataObjects that map one-to-one to a
> database
> > > table.
> > > > >
> > > > > Thanks in advance for your assistance/insights,
> > > > >
> > > > > - Ron
> > > > >
> > > > >
> > > > >
> > > > >
> > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Luciano Resende
> > > http://people.apache.org/~lresende
> > >
> >
> >
>

Re: Tuscany DAS Features/Questions

[Amita Vadhavkar <am...@gmail.com>]

Hi Folks,
Can I create JIRAs for these and mark them for DAS Mx, just to have a
pointer to come back to these features?
Regards,
Amita

On 5/15/07, Amita Vadhavkar <am...@gmail.com> wrote:
>
> It will be interesting to get these features into DAS using JIRAs.
> I am just trying to get a clear picture of what all details these features
> can consist.
>
> 1. This can be support for explicit as well as SDO-integrated
> inserts/updates
>
> 2. a. Here validations can be based on Database provided Meta Data, also,
> we can think of defining custom validations per Command basis in DAS
> config. What do you think?
>
> 2. b. As part of {2. c. 2>} , This will have more control on individual
> DataGraphs contained
> in the root Data Graph. With this, invalid (validation failed) Data Graphs
> can be
> deleted from the tree. The dependency management logic will need to handle
> the consequent
> actions for this deletion(parent-child etc.).
> 2. c. There can be 2 situations -
> 1> when the data graphs are not of related database entities, here
> different config files can split the work
> 2> when they are for related entities, the worker threads will be sharing
> part of load
> of same transaction.
>
> Please add your thoughts and any more desirable but missing features, that
> DAS can
> take up.
>
> Regards,
> Amita
>
>
>  On 5/15/07, Luciano Resende <lu...@gmail.com> wrote:
> >
> > Should we start creating some JIRAs for these enhancement requests ?
> >
> > On 5/14/07, Brent Daniel < brenthdaniel@gmail.com> wrote:
> > >
> > > 1. Not today, though I think this would be a good feature for the DAS
> > > to pick up.
> > >
> > > 2 a. No, but that would be an interesting capability. Today I think
> > > validation would best be performed at the client level.
> > >
> > > b. It's probably easiest to do this on a case by case basis..
> > > Unfortunately I don't think there's an easy way to undo individual
> > > changes (though you can always undo everything using
> > > ChangeSummary.undoChanges()).  To undo an insert, you can simply
> > > delete the DataObject. For property changes, you can use
> > > changeSummary.getOldValues () to get the previous values and re-set
> > > them. I'm not sure if anything easier is coming in future versions of
> > > SDO or not.
> > >
> > > c. The DAS has some paging capability for situations like this. From
> > > your description of your application, it sounds like you may also be
> > > able to simply break the app down so that you use several different
> > > config files with independent DataGraphs.
> > >
> > > Brent
> > >
> > >
> > > On 5/11/07, Ron Gavlin <rg...@yahoo.com> wrote:
> > > > Greetings,
> > > >
> > > > We are considering replacing some of our custom, home-grown DAS'
> > with
> > > Tuscany DAS. As a result, I have a few Tuscany DAS questions.
> > > >
> > > > 1. Does the Tuscany DAS have any support for JDBC Batch
> > Update/Insert
> > > operations?
> > > >
> > > > 2. I have a multi-tiered application in which I send a DataGraph of
> > > DataObjects from the middle-tier to a client and later receive the
> > updated
> > > DataGraph from that client. I would like to apply validation to some
> > of the
> > > DataObjects in the DataGraph before the changes are persisted to the
> > > database.
> > > >
> > > >    a. Is there a mechanism for integrating my validation into the
> > DAS'
> > > applyChanges() operation to avoid the overhead of traversing the
> > > ChangeSummary twice, once by me and once by the DAS?
> > > >
> > > >    b. When a single DataObject fails validation, what is the best
> > way
> > > for me to undo the changes to that particular DataObject so the DAS
> > ignores
> > > just those changes and doesn't persist them to the database?
> > > >
> > > >    c. The DataGraph of changed DataObjects if often large in my
> > > application. Also, my custom validation logic is quite expensive. So,
> > I
> > > would like to break the DataGraph into multiple "sub-DataGraphs" and
> > execute
> > > the validation logic and the DAS' applyChanges() on separate
> > WorkManager
> > > threads. I am doing something like that today with my own home-grown
> > DAS
> > > that is custom to my trivial data model, whereby the DataGraph is
> > simply a
> > > container for a list of DataObjects that map one-to-one to a database
> > table.
> > > >
> > > > Thanks in advance for your assistance/insights,
> > > >
> > > > - Ron
> > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende
> >
>
>

Re: Tuscany DAS Features/Questions

[Amita Vadhavkar <am...@gmail.com>]

Hi Folks,
Can I create JIRAs for these and mark them for DAS Mx, just to have a
pointer to come back to these features?
Regards,
Amita

On 5/15/07, Amita Vadhavkar <am...@gmail.com> wrote:
>
> It will be interesting to get these features into DAS using JIRAs.
> I am just trying to get a clear picture of what all details these features
> can consist.
>
> 1. This can be support for explicit as well as SDO-integrated
> inserts/updates
>
> 2. a. Here validations can be based on Database provided Meta Data, also,
> we can think of defining custom validations per Command basis in DAS
> config. What do you think?
>
> 2. b. As part of {2. c. 2>} , This will have more control on individual
> DataGraphs contained
> in the root Data Graph. With this, invalid (validation failed) Data Graphs
> can be
> deleted from the tree. The dependency management logic will need to handle
> the consequent
> actions for this deletion(parent-child etc.).
> 2. c. There can be 2 situations -
> 1> when the data graphs are not of related database entities, here
> different config files can split the work
> 2> when they are for related entities, the worker threads will be sharing
> part of load
> of same transaction.
>
> Please add your thoughts and any more desirable but missing features, that
> DAS can
> take up.
>
> Regards,
> Amita
>
>
>  On 5/15/07, Luciano Resende <lu...@gmail.com> wrote:
> >
> > Should we start creating some JIRAs for these enhancement requests ?
> >
> > On 5/14/07, Brent Daniel < brenthdaniel@gmail.com> wrote:
> > >
> > > 1. Not today, though I think this would be a good feature for the DAS
> > > to pick up.
> > >
> > > 2 a. No, but that would be an interesting capability. Today I think
> > > validation would best be performed at the client level.
> > >
> > > b. It's probably easiest to do this on a case by case basis..
> > > Unfortunately I don't think there's an easy way to undo individual
> > > changes (though you can always undo everything using
> > > ChangeSummary.undoChanges()).  To undo an insert, you can simply
> > > delete the DataObject. For property changes, you can use
> > > changeSummary.getOldValues () to get the previous values and re-set
> > > them. I'm not sure if anything easier is coming in future versions of
> > > SDO or not.
> > >
> > > c. The DAS has some paging capability for situations like this. From
> > > your description of your application, it sounds like you may also be
> > > able to simply break the app down so that you use several different
> > > config files with independent DataGraphs.
> > >
> > > Brent
> > >
> > >
> > > On 5/11/07, Ron Gavlin <rg...@yahoo.com> wrote:
> > > > Greetings,
> > > >
> > > > We are considering replacing some of our custom, home-grown DAS'
> > with
> > > Tuscany DAS. As a result, I have a few Tuscany DAS questions.
> > > >
> > > > 1. Does the Tuscany DAS have any support for JDBC Batch
> > Update/Insert
> > > operations?
> > > >
> > > > 2. I have a multi-tiered application in which I send a DataGraph of
> > > DataObjects from the middle-tier to a client and later receive the
> > updated
> > > DataGraph from that client. I would like to apply validation to some
> > of the
> > > DataObjects in the DataGraph before the changes are persisted to the
> > > database.
> > > >
> > > >    a. Is there a mechanism for integrating my validation into the
> > DAS'
> > > applyChanges() operation to avoid the overhead of traversing the
> > > ChangeSummary twice, once by me and once by the DAS?
> > > >
> > > >    b. When a single DataObject fails validation, what is the best
> > way
> > > for me to undo the changes to that particular DataObject so the DAS
> > ignores
> > > just those changes and doesn't persist them to the database?
> > > >
> > > >    c. The DataGraph of changed DataObjects if often large in my
> > > application. Also, my custom validation logic is quite expensive. So,
> > I
> > > would like to break the DataGraph into multiple "sub-DataGraphs" and
> > execute
> > > the validation logic and the DAS' applyChanges() on separate
> > WorkManager
> > > threads. I am doing something like that today with my own home-grown
> > DAS
> > > that is custom to my trivial data model, whereby the DataGraph is
> > simply a
> > > container for a list of DataObjects that map one-to-one to a database
> > table.
> > > >
> > > > Thanks in advance for your assistance/insights,
> > > >
> > > > - Ron
> > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende
> >
>
>