Amita,
It seems like it might be better to require qualification of the
stored procedure. It's probably around the same amount of work for the
user, but makes the config and das implementation simpler.
Brent
On 2/21/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
Hi Kevin,
Thanks a lot for the information.
For 3), I have one more question, If we consider db stored procs,
then we may need to treat the Command where kind="procedure" a bit more
differently. This is because, when stored proc is a db entity, it resides in
the db
and can be part of any db schema. So, when looking at JIRA-952, to give a
complete
solution, we will need to add schemaName attribute for <Command> and this
will be
valid only for kind="procedure".
Or otherwise, we need to document (and programmatically check ) that when
multiple schema
support is ON, then the name of stored proc appearing in "call xyz" command
is fully
qualified (i.e. prepended with some schema name). In this case we do not
need schemaName attribute in <Command>.
What is your advise?
Regards,
Amita
On 2/22/07, Kevin Williams <[EMAIL PROTECTED]> wrote:
>
> Hi Amita,
> Comments in line ...
>
> Amita Vadhavkar wrote:
>
> > Hi All,
> > When going through DAS code and documentation, I had a couple of
> > questions ,
> > as listed below. It will really be helpful to get more detail
> information
> > for same.
> >
> > 1) what conventions are followed in OCC? - This was listed in the
> > guide that
> > OCC is going to follow some
> > config convention.
>
> Currently, in the absence of configuration declaring an OCC column, the
> DAS will default to over qualifying all changed columns.
> OCCTests.testAutomaticOCC demonstrates this.
>
> > 2) root.get("CUSTOMER[1]"); is supported and there are plenty of
> > examples.
> > What about root.get("CUSTOMER[name='Patrick']"); Could not find any
> > examples for this.
>
> This is an SDO feature and your example should work with this slight
> change: root.getDataObject("CUSTOMER[name='Patrick']");
>
> > In this case, if multiple rows/DOs are returned, how these are handled
> in
> > places like applyChanges() ?
>
> This is SDO traversal or "read" behavior and there is no impact on
> DAS.applyChanges()
>
> > 3) We are considering only java stored procedure as of now , any plans
> > for
> > considering database stored procedures?
>
> Java stored procedures are used for the unit tests since they are easy
> to automate. The DAS SP capability will work with non-Java stored
> procedure implementations as well.
>
> >
> >
> > Regards,
> > Amita
> >
>
>
>
> ---------------------------------------------------------------------
> 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]
