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
