You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Amita Vadhavkar <am...@gmail.com> on 2007/02/21 12:47:15 UTC
[DAS] Questions regarding some details of DAS features
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.
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.
In this case, if multiple rows/DOs are returned, how these are handled in
places like applyChanges() ?
3) We are considering only java stored procedure as of now , any plans for
considering database stored procedures?
Regards,
Amita
Re: [DAS] Questions regarding some details of DAS features
Posted by Brent Daniel <br...@gmail.com>.
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 <am...@gmail.com> 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 <ke...@qwest.net> 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: 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: [DAS] Questions regarding some details of DAS features
Posted by Amita Vadhavkar <am...@gmail.com>.
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 <ke...@qwest.net> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [DAS] Questions regarding some details of DAS features
Posted by Kevin Williams <ke...@qwest.net>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org