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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> >
> > Should we start creating some JIRAs for these enhancement requests ?
> >
> > On 5/14/07, Brent Daniel < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende
> >
>
>
