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/07/12 10:03:51 UTC
[RDB DAS] Consistent use of Parameters in Config
Hi,
A few days ago there was a user question about passing name in Parameter:-
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html
When checking how Parameters are used in Config, came across the following
points.
There is a difference in Config (SDO) generated Parameter and
org.apache.tuscany.das.rdb.impl.ParameterImpl.
The one from Config has only ColumnType, Direction and Index whereas in
impl, it has
in addition Name and some other attributes. Not having Name in Config
generated version
does not cause any problems anywhere as JDBC PreparedStatement
setParameter() requires
Index and not Name. But to give a consistent user experience, it can be good
to add Name
(Optional).
Also, when supporting <Create>, <Update>, <Delete> in RDB DAS Config, the
attribute
"parameters" is String, which is internally interpreted in Index and Name.
This misses
the ColumnType and Direction.Direction can be safely assumed as IN for these
statements.
Also, not supplying ColumnType again causes no issues, as DAS tries to get
it from database
metadata or using SDO standards. Still here again, if user can specify
ColumnType (optional),
it will give a consistent user experiece.
So, question here, for the sake of consistency and uniform user experience,
is it a good
idea to replace [1] with [2]? (Same for <Update> and <Delete>)
[1]<xsd:complexType name="Create">
<xsd:attribute name="sql" type="xsd:string"/>
<xsd:attribute name="parameters" type="xsd:string"/>
</xsd:complexType>
[2]<xsd:complexType name="Create">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="Parameter"
type="config:Parameter"/>
</xsd:sequence>
<xsd:attribute name="sql" type="xsd:string"/>
</xsd:complexType>
Regards,
Amita
Re: [RDB DAS] Consistent use of Parameters in Config
Posted by Amita Vadhavkar <am...@gmail.com>.
I agree, it is the right time to remove this backward compatibility, as in
future , it can add to more confusion. I am chaning the patch for this. (
i.e. removing List and any related methods). Please give any other review
comments.
Regards,
Amita
On 9/3/07, Adriano Crestani <ad...@apache.org> wrote:
>
> Hi everyone,
>
> I wonder if it is really necessary to keep the back compatibility keeping
> the List attribute, once the Tuscany DAS Java is still in beta phase of
> develpment. What do you think?
>
> Regards,
> Adriano Crestani
>
> On 8/30/07, Amita Vadhavkar <am...@gmail.com> wrote:
> >
> > Thanks Kevin, for correcting the example, I actually meant what you have
> > assumed :)
> >
> > Also, another question in JDK5 context, the code will be very precise
> and
> > type checking/assumptions about types can be avoided in many places in
> DAS
> > using JDK5 generics. Other features from JDK5 can be used too. So, I am
> > just
> > curious to know the different
> > pros and cons about using JDK1.4 vs. using JDK5.
> >
> > Regards,
> > Amita
> >
> > On 8/30/07, Kevin Williams <kj...@gmail.com> wrote:
> > >
> > > This sounds good to me since programming model consistency is so very
> > > important. I agree that partial index specification should *not* be
> > > supported. I was concerned by your example:
> > >
> > > <Parameters>
> > > <Parameter name="ID" index="1"/> -- rest of the attributes
> > optional
> > > <Parameter name="LASTNAME" /> -- rest of the attributes
> optional
> > > <Parameter name="ADDRESS" /> -- rest of the attributes
> optional
> > > </Parameters>
> > >
> > > But, i assume you meant
> > >
> > > <Parameters>
> > > <Parameter name="ID" index="1"/> -- rest of the attributes
> > optional
> > > <Parameter name="LASTNAME" index="2"/> -- rest of the
> > > attributes optional
> > > <Parameter name="ADDRESS" index="3"/> -- rest of the
> attributes
> > > optional
> > > </Parameters>
> > >
> > > --Kevin
> > >
> > > On 8/29/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > > Below is one of the use cases where user will get some benefit:-
> > > >
> > > > USE CASE:
> > > > bigtable{col1, col2,....col50}
> > > >
> > > > SIMPLEST CLIENT CODE: WITH NAMED PARAM SUPPORT
> > > > Command insertAdhoc = das.createCommand("insert into bigtable values
> > (?,
> > > ?,
> > > > ?...50 times)");
> > > > insertAdhoc.setParameter("ID", new Integer(6));
> > > > insertAdhoc.setParameter("LASTNAME", "MyLastName");
> > > > insertAdhoc.setParameter("ADDRESS", "MyLastAddress");
> > > > ...
> > > > insertAdhoc.setParameter("Param50", "Value50");
> > > >
> > > > COMPARE WITH EXISTING WAY: WITHOUT NAMED PARAM SUPPORT
> > > > Command insertAdhoc = das.createCommand("insert into bigtable values
> > (?,
> > > ?,
> > > > ?...50 times)");
> > > > insertAdhoc.setParameter(1, new Integer(6));
> > > > insertAdhoc.setParameter(2, "MyLastName");
> > > > insertAdhoc.setParameter(3, "MyLastAddress");
> > > > ...
> > > > insertAdhoc.setParameter(50, "Value50");
> > > >
> > > >
> > >
> >
> ------------------------------------------------------------------------------------------------
> > > > Summary of previous discussion and main intention of this JIRA is to
> > > support
> > > > the below features:-
> > > > 1) Add attribute "Name" to parameter for user
> convenience/readability
> > > > 2) Support command.setParameter(name, value) for user
> > > > convenience/readability
> > > > 3) Preserve existing ways of using parameters - e.g.
> > > > A>
> > > > Continue supporting -
> > > > <Table tableName="CUSTOMER">
> > > > <create sql="insert into customer values (?, ?, ?)">
> > > > <Parameters List="ID LASTNAME ADDRESS"> </Parameters>
> > > > </create>
> > > > </Table>
> > > >
> > > > But also support -
> > > > <Table tableName="CUSTOMER">
> > > > <create sql="insert into customer values (?, ?, ?)" >
> > > > <Parameters>
> > > > <Parameter name="ID" index="1"/> -- rest of the attributes
> > > optional
> > > > <Parameter name="LASTNAME" /> -- rest of the attributes
> > optional
> > > > <Parameter name="ADDRESS" /> -- rest of the attributes
> optional
> > > > </Parameters>
> > > > </create>
> > > > </Table>
> > > >
> > > > Note: if +ve index is specified in Parameter, it is used, else
> > > > auto-increment similar to A> is used. As List is an ordered
> > collection,
> > > the
> > > > sequence appearing in the cofig file will be maintained. Partially
> > > > specifying indexes is not supported (i.e. give index for 2 out of 3
> > > params
> > > > and leave one without it, is not supported)
> > > >
> > > > B>
> > > > Continue supporting -
> > > > cmd.setParameter(1, new Integer(1)); cmd.getParameter(1);
> > > >
> > > > But also support -
> > > > cmd.setParameter("BOOKS.BOOK_ID", new Integer(1));
> > > > cmd.getParameter("BOOKS.BOOK_ID");
> > > >
> > > > C>
> > > > Continue supporting -
> > > > <Command...
> > > > <Parameter/>
> > > > <Parameter/>
> > > > </Command>
> > > >
> > > > And
> > > >
> > > > <Command..........No Params in Config, but directly
> > > setParameter(idx/name,
> > > > value) in program
> > > > </Command>
> > > >
> > > > But also support
> > > >
> > > > Command insertAdhoc = das.createCommand("insert into CUSTOMER values
> > (?,
> > > ?,
> > > > ?)");
> > > > insertAdhoc.setParameter("ID", new Integer(6));
> > > > insertAdhoc.setParameter("LASTNAME", "MyLastName");
> > > > insertAdhoc.setParameter("ADDRESS", "MyLastAddress");
> > > >
> > > > Note: Convention over config is followed, if Parameters are not
> > defined
> > > in
> > > > config, the sequence
> > > > should match the table columns [convention],else user should specify
> > > params
> > > > on command in config and specify index attributes in them [config]
> > > >
> > > > 4) This JIRA code will benefit a lot by use of JDK5 generics, but as
> > DAS
> > > is
> > > > still at JDK1.4 level current code does not use generics.
> > > >
> > > > 5) Changes in config -
> > > > <xsd:complexType name="Create">
> > > > <xsd:sequence>
> > > > <xsd:element maxOccurs="1" minOccurs="0" name="Parameters"
> > > > type="config:Parameters"/>
> > > > </xsd:sequence>
> > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > </xsd:complexType>
> > > > ....Similar for Update and Delete.................
> > > >
> > > > <xsd:complexType name="Parameter">
> > > > <xsd:attribute name="name" type="xsd:string"/>
> > > > <xsd:attribute name="columnType" type="xsd:string"/>
> > > > <xsd:attribute name="direction"
> type="xsd:string" default="IN"/>
> > > > <xsd:attribute name="index" type="xsd:int"/>
> > > > </xsd:complexType>
> > > >
> > > > <xsd:complexType name="Parameters">
> > > > <xsd:sequence>
> > > > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > > name="Parameter"
> > > > type="config:Parameter"/>
> > > > </xsd:sequence>
> > > > <xsd:attribute name="List" type="xsd:string"/>
> > > > </xsd:complexType>
> > > >
> > > > **Note** In <Parameters> Either List attribute OR Parameter element
> is
> > > used
> > > > BUT not both at a time. Attribut "List" is just to preserve existing
> > > > convenience as in 3) A>
> > > >
> > > > 6) Existing test cases changes -
> > > > No changes needed in existing xml configs
> > > > Only 2 assertions changed in ProgrammaticConfigTests.
> > > >
> > > > 7) Exact code change and new test case details in JIRA-1462 comment
> > > >
> > > > Regards,
> > > > Amita
> > > >
> > > > On 8/3/07, Adriano Crestani <ad...@apache.org> wrote:
> > > > >
> > > > > I agree with Amita that for clarity is better to let the user set
> > the
> > > > > parameter name, for all those reasons she has argued on this
> thread
> > so
> > > > > far.
> > > > > But, I don't I agree with to use the [1] instead of [2], because
> > it's
> > > not
> > > > > a
> > > > > good practice to define the parameter names on only one string
> > > separated
> > > > > by
> > > > > spaces, it's not a good practice, mainly when we're dealing with
> > XML.
> > > > >
> > > > > My suggestion is to use [2], but add the <xsd:attribute
> name="name"
> > > > > type="xsd:string"> on Parameter ComplexType and also keep the
> index
> > > > > attribute on it. These way both methods, customer.set
> > > ("pararmeterName",
> > > > > "value") and customer.setParameter(parameterIndex, "value) will be
> > > > > supported.
> > > > >
> > > > > However, on any of these cases, the user will need to define a
> > > parameter N
> > > > > times if there are N commands that use it. I don't see any
> solution
> > > for
> > > > > these case : (
> > > > >
> > > > > Regards,
> > > > > Adriano Crestani
> > > > >
> > > > >
> > > > > [1]<xsd:complexType name="Create">
> > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > <xsd:attribute name="parameters" type="xsd:string"/>
> > > > > </xsd:complexType>
> > > > >
> > > > >
> > > > > [2]<xsd:complexType name="Create">
> > > > > <xsd:sequence>
> > > > > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > > > > name="Parameter"
> > > > > type="config:Parameter"/>
> > > > > </xsd:sequence>
> > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > </xsd:complexType>
> > > > >
> > > > >
> > > > > On 8/2/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > > > >
> > > > > > JPQL, Hibernate ,... have support for named parameters.
> > > > > >
> > > > > > Why is RDB DAS going in the other way? If there is a reason for
> > > > > switching
> > > > > > off named parameters, please elaborate, else is it OK to go for
> > > > > JIRA-1462?
> > > > > >
> > > > > > Regards,
> > > > > > Amita
> > > > > >
> > > > > > On 7/13/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > > > > >
> > > > > > > I went through [1] and [2], it talks about removing name
> > attribute
> > > > > from
> > > > > > > Parameter
> > > > > > > and about generatedKeys. Also saw JIRA-528 on the way. But I
> > could
> > > not
> > > > > > get
> > > > > > > the exact
> > > > > > > rational behind removing Name from Parameter (It is definitely
> > not
> > > > > > > required
> > > > > > > by JDBC for sure, but can have some aid in usage clarity)....
> > > > > > >
> > > > > > > 1)One place in RDB DAS (here Name is not removed and can not
> be
> > > > > removed)
> > > > > > > BasicCustomerMappingWithCUD.xml (
> > > > > > CRUDWithChangeHistory.testDeleteAndCreate
> > > > > > > ())
> > > > > > > <Config xmlns="http:///org.apache.tuscany.das.rdb/config.xsd">
> > > > > > >
> > > > > > > <Table tableName="CUSTOMER">
> > > > > > > <create sql="insert into customer values (?, ?, ?)"
> > > > > parameters="ID
> > > > > > > LASTNAME ADDRESS"/>
> > > > > > > <update sql="update customer set lastname = ?, address =
> ?
> > > where
> > > > > > ID
> > > > > > > = ?" parameters="LASTNAME ADDRESS ID"/>
> > > > > > > <delete sql="delete from customer where ID = ?"
> > > > > parameters="ID"/>
> > > > > > > </Table>
> > > > > > >
> > > > > > > </Config>
> > > > > > >
> > > > > > > This is informative because we have <create sql="insert into
> > > customer
> > > > > > > values (?, ?, ?)" parameters="ID LASTNAME ADDRESS"/>
> > > > > > > In the client code we will typically have
> > > > > > > DataObject customer = root.createDataObject
> ("CUSTOMER");
> > > > > > > customer.setInt("ID", 720);
> > > > > > > customer.set("LASTNAME", "foobar");
> > > > > > > customer.set("ADDRESS", "asdfasdf");
> > > > > > >
> > > > > > > das.applyChanges(root);
> > > > > > >
> > > > > > > Here client has a chance to understand that he needs to set
> ID,
> > > > > > LASTNAME,
> > > > > > > ADDRESS because the config states - parameters="ID LASTNAME
> > > ADDRESS"
> > > > > > and
> > > > > > > internally we will map names to idx when doing
> > > > > > > PreparedStatement.setParameter.
> > > > > > >
> > > > > > > For the matter of whether it is required to have
> parameters="ID
> > > > > LASTNAME
> > > > > > > ADDRESS" , it is required. We can no say parameters="1 2 3"
> or
> > "X
> > > Y
> > > > > Z"
> > > > > > > because during SDO to Parameter mapping (in ChangeOperation)
> we
> > > need
> > > > > > the
> > > > > > > Name of parameter, so Name and Idx both are required.
> > > > > > >
> > > > > > > 2)Another place in RDB DAS (this is where Name is removed in
> > > JIRA-658)
> > > > > > > <Command name="InsertCustomers" SQL="insert into CUSTOMER
> > > values
> > > > > > > (?,?,?) " kind="Insert">
> > > > > > > <Parameter direction="IN" index="1" columnType="
> > > > > > commonj.sdo.IntObject
> > > > > > > "/>
> > > > > > > <Parameter direction="IN" index="2" columnType="
> > > > > > commonj.sdo.String"/>
> > > > > > >
> > > > > > > <Parameter direction="IN" index="3" columnType="
> > > > > > commonj.sdo.String"/>
> > > > > > >
> > > > > > > </Command>
> > > > > > >
> > > > > > > A typical client code will be,
> > > > > > > Command insert = das.getCommand("InsertCustomers");
> > > > > > > insert.setParameter(1, "1000");
> > > > > > > insert.setParameter(2, "MYNAME");
> > > > > > > insert.setParameter(3, "MYADDR");
> > > > > > > insert.execute();
> > > > > > >
> > > > > > > In this example, nowhere the client has a way to know what
> 1000,
> > > > > MYNAME
> > > > > > or
> > > > > > > MYADDRESS means. If this is a table with many columns and
> such
> > > many
> > > > > > tables,
> > > > > > > how the client is going to set values using setParameter()
> with
> > > any
> > > > > > comfort
> > > > > > > level, unless otherwise the he has a direct access to database
> > and
> > > can
> > > > > > know
> > > > > > > the names and order or columns in database table or if the
> > insert
> > > > > syntax
> > > > > > is
> > > > > > > used
> > > > > > > like "insert into CUSTOMER (ID, LASTNAME, ADDRESS) values
> > (?,?,?)
> > > "
> > > > > > >
> > > > > > > but in tables having large number of rows, it is likely that
> > > client
> > > > > will
> > > > > > > try to have short
> > > > > > > (insert) statements without column names. And this is what I
> > felt
> > > was
> > > > > > the
> > > > > > > issue of the user in
> > > > > > >
> > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html,
> > > > > as
> > > > > > he
> > > > > > > admitted that even though JDBC does not need Names, he needs
> it
> > > for
> > > > > the
> > > > > > sake
> > > > > > > of clarity.
> > > > > > >
> > > > > > > So, as such, first thig I am just curious to know is, what
> were
> > > the
> > > > > > > advantages of JIRA-658?
> > > > > > >
> > > > > > > Also, not quite clear about "Also, have you thought about
> > multiple
> > > > > > queries
> > > > > > > retrieving the same column,you would have to configure the
> > > parameter
> > > > > in
> > > > > > > multiple places." If there are 10 different Select Commands
> with
> > > 10
> > > > > > > different Where clauses, we anyway need to set Parameters in
> 10
> > > > > > different
> > > > > > > places.
> > > > > > >
> > > > > > > I guess I am completely intepreting something wrong here,
> please
> > > help.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Amita
> > > > > > >
> > > > > > > On 7/13/07, Luciano Resende <lu...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > The named parameter support was removed from earlier
> versions
> > of
> > > > > DAS,
> > > > > > > > here is some previous discussion around the subject [1] See
> > also
> > > > > > > > tuscany-658. We might need to do further cleanup on the
> impl,
> > if
> > > I
> > > > > > > > understood correctly.
> > > > > > > >
> > > > > > > > As for your second suggestion (parameter column types),
> could
> > > you
> > > > > > > > expose some use cases scenarios where this would be helpful
> ?
> > > Also,
> > > > > > > > have you thought about multiple queries retrieving the same
> > > column,
> > > > > > > > you would have to configure the parameter in multiple
> places.
> > > > > > > >
> > > > > > > > [1]
> > > > > >
> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04672.html
> > > > > > > > [2] http://issues.apache.org/jira/browse/TUSCANY-658
> > > > > > > >
> > > > > > > > On 7/12/07, Amita Vadhavkar <am...@gmail.com>
> wrote:
> > > > > > > > > Hi,
> > > > > > > > > A few days ago there was a user question about passing
> name
> > in
> > > > > > > > Parameter:-
> > > > > > > > >
> > > > >
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html
> > > > > > > > >
> > > > > > > > > When checking how Parameters are used in Config, came
> across
> > > the
> > > > > > > > following
> > > > > > > > > points.
> > > > > > > > > There is a difference in Config (SDO) generated Parameter
> > and
> > > > > > > > > org.apache.tuscany.das.rdb.impl.ParameterImpl.
> > > > > > > > >
> > > > > > > > > The one from Config has only ColumnType, Direction and
> Index
> > > > > whereas
> > > > > > > > in
> > > > > > > > > impl, it has
> > > > > > > > > in addition Name and some other attributes. Not having
> Name
> > in
> > > > > > Config
> > > > > > > > > generated version
> > > > > > > > > does not cause any problems anywhere as JDBC
> > PreparedStatement
> > > > > > > > > setParameter() requires
> > > > > > > > > Index and not Name. But to give a consistent user
> > experience,
> > > it
> > > > > can
> > > > > > > > be good
> > > > > > > > > to add Name
> > > > > > > > > (Optional).
> > > > > > > > >
> > > > > > > > > Also, when supporting <Create>, <Update>, <Delete> in RDB
> > DAS
> > > > > > Config,
> > > > > > > > the
> > > > > > > > > attribute
> > > > > > > > > "parameters" is String, which is internally interpreted in
> > > Index
> > > > > and
> > > > > > > > Name.
> > > > > > > > > This misses
> > > > > > > > > the ColumnType and Direction.Direction can be safely
> assumed
> > > as IN
> > > > > > for
> > > > > > > > these
> > > > > > > > > statements.
> > > > > > > > > Also, not supplying ColumnType again causes no issues, as
> > DAS
> > > > > tries
> > > > > > to
> > > > > > > > get
> > > > > > > > > it from database
> > > > > > > > > metadata or using SDO standards. Still here again, if user
> > can
> > > > > > specify
> > > > > > > > > ColumnType (optional),
> > > > > > > > > it will give a consistent user experiece.
> > > > > > > > >
> > > > > > > > > So, question here, for the sake of consistency and uniform
> > > user
> > > > > > > > experience,
> > > > > > > > > is it a good
> > > > > > > > > idea to replace [1] with [2]? (Same for <Update> and
> > <Delete>)
> > > > > > > > >
> > > > > > > > > [1]<xsd:complexType name="Create">
> > > > > > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > > > > > <xsd:attribute name="parameters"
> > type="xsd:string"/>
> > > > > > > > > </xsd:complexType>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > [2]<xsd:complexType name="Create">
> > > > > > > > > <xsd:sequence>
> > > > > > > > > <xsd:element maxOccurs="unbounded"
> minOccurs="0"
> > > > > > > > name="Parameter"
> > > > > > > > > type="config:Parameter"/>
> > > > > > > > > </xsd:sequence>
> > > > > > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > > > > > </xsd:complexType>
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Amita
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Luciano Resende
> > > > > > > > Apache Tuscany Committer
> > > > > > > > http://people.apache.org/~lresende<
> > > > > > http://people.apache.org/%7Elresende>
> > > > > > > > http://lresende.blogspot.com/
> > > > > > > >
> > > > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > > > 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-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> >
>
Re: [RDB DAS] Consistent use of Parameters in Config
Posted by Adriano Crestani <ad...@apache.org>.
Hi everyone,
I wonder if it is really necessary to keep the back compatibility keeping
the List attribute, once the Tuscany DAS Java is still in beta phase of
develpment. What do you think?
Regards,
Adriano Crestani
On 8/30/07, Amita Vadhavkar <am...@gmail.com> wrote:
>
> Thanks Kevin, for correcting the example, I actually meant what you have
> assumed :)
>
> Also, another question in JDK5 context, the code will be very precise and
> type checking/assumptions about types can be avoided in many places in DAS
> using JDK5 generics. Other features from JDK5 can be used too. So, I am
> just
> curious to know the different
> pros and cons about using JDK1.4 vs. using JDK5.
>
> Regards,
> Amita
>
> On 8/30/07, Kevin Williams <kj...@gmail.com> wrote:
> >
> > This sounds good to me since programming model consistency is so very
> > important. I agree that partial index specification should *not* be
> > supported. I was concerned by your example:
> >
> > <Parameters>
> > <Parameter name="ID" index="1"/> -- rest of the attributes
> optional
> > <Parameter name="LASTNAME" /> -- rest of the attributes optional
> > <Parameter name="ADDRESS" /> -- rest of the attributes optional
> > </Parameters>
> >
> > But, i assume you meant
> >
> > <Parameters>
> > <Parameter name="ID" index="1"/> -- rest of the attributes
> optional
> > <Parameter name="LASTNAME" index="2"/> -- rest of the
> > attributes optional
> > <Parameter name="ADDRESS" index="3"/> -- rest of the attributes
> > optional
> > </Parameters>
> >
> > --Kevin
> >
> > On 8/29/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > Below is one of the use cases where user will get some benefit:-
> > >
> > > USE CASE:
> > > bigtable{col1, col2,....col50}
> > >
> > > SIMPLEST CLIENT CODE: WITH NAMED PARAM SUPPORT
> > > Command insertAdhoc = das.createCommand("insert into bigtable values
> (?,
> > ?,
> > > ?...50 times)");
> > > insertAdhoc.setParameter("ID", new Integer(6));
> > > insertAdhoc.setParameter("LASTNAME", "MyLastName");
> > > insertAdhoc.setParameter("ADDRESS", "MyLastAddress");
> > > ...
> > > insertAdhoc.setParameter("Param50", "Value50");
> > >
> > > COMPARE WITH EXISTING WAY: WITHOUT NAMED PARAM SUPPORT
> > > Command insertAdhoc = das.createCommand("insert into bigtable values
> (?,
> > ?,
> > > ?...50 times)");
> > > insertAdhoc.setParameter(1, new Integer(6));
> > > insertAdhoc.setParameter(2, "MyLastName");
> > > insertAdhoc.setParameter(3, "MyLastAddress");
> > > ...
> > > insertAdhoc.setParameter(50, "Value50");
> > >
> > >
> >
> ------------------------------------------------------------------------------------------------
> > > Summary of previous discussion and main intention of this JIRA is to
> > support
> > > the below features:-
> > > 1) Add attribute "Name" to parameter for user convenience/readability
> > > 2) Support command.setParameter(name, value) for user
> > > convenience/readability
> > > 3) Preserve existing ways of using parameters - e.g.
> > > A>
> > > Continue supporting -
> > > <Table tableName="CUSTOMER">
> > > <create sql="insert into customer values (?, ?, ?)">
> > > <Parameters List="ID LASTNAME ADDRESS"> </Parameters>
> > > </create>
> > > </Table>
> > >
> > > But also support -
> > > <Table tableName="CUSTOMER">
> > > <create sql="insert into customer values (?, ?, ?)" >
> > > <Parameters>
> > > <Parameter name="ID" index="1"/> -- rest of the attributes
> > optional
> > > <Parameter name="LASTNAME" /> -- rest of the attributes
> optional
> > > <Parameter name="ADDRESS" /> -- rest of the attributes optional
> > > </Parameters>
> > > </create>
> > > </Table>
> > >
> > > Note: if +ve index is specified in Parameter, it is used, else
> > > auto-increment similar to A> is used. As List is an ordered
> collection,
> > the
> > > sequence appearing in the cofig file will be maintained. Partially
> > > specifying indexes is not supported (i.e. give index for 2 out of 3
> > params
> > > and leave one without it, is not supported)
> > >
> > > B>
> > > Continue supporting -
> > > cmd.setParameter(1, new Integer(1)); cmd.getParameter(1);
> > >
> > > But also support -
> > > cmd.setParameter("BOOKS.BOOK_ID", new Integer(1));
> > > cmd.getParameter("BOOKS.BOOK_ID");
> > >
> > > C>
> > > Continue supporting -
> > > <Command...
> > > <Parameter/>
> > > <Parameter/>
> > > </Command>
> > >
> > > And
> > >
> > > <Command..........No Params in Config, but directly
> > setParameter(idx/name,
> > > value) in program
> > > </Command>
> > >
> > > But also support
> > >
> > > Command insertAdhoc = das.createCommand("insert into CUSTOMER values
> (?,
> > ?,
> > > ?)");
> > > insertAdhoc.setParameter("ID", new Integer(6));
> > > insertAdhoc.setParameter("LASTNAME", "MyLastName");
> > > insertAdhoc.setParameter("ADDRESS", "MyLastAddress");
> > >
> > > Note: Convention over config is followed, if Parameters are not
> defined
> > in
> > > config, the sequence
> > > should match the table columns [convention],else user should specify
> > params
> > > on command in config and specify index attributes in them [config]
> > >
> > > 4) This JIRA code will benefit a lot by use of JDK5 generics, but as
> DAS
> > is
> > > still at JDK1.4 level current code does not use generics.
> > >
> > > 5) Changes in config -
> > > <xsd:complexType name="Create">
> > > <xsd:sequence>
> > > <xsd:element maxOccurs="1" minOccurs="0" name="Parameters"
> > > type="config:Parameters"/>
> > > </xsd:sequence>
> > > <xsd:attribute name="sql" type="xsd:string"/>
> > > </xsd:complexType>
> > > ....Similar for Update and Delete.................
> > >
> > > <xsd:complexType name="Parameter">
> > > <xsd:attribute name="name" type="xsd:string"/>
> > > <xsd:attribute name="columnType" type="xsd:string"/>
> > > <xsd:attribute name="direction" type="xsd:string" default="IN"/>
> > > <xsd:attribute name="index" type="xsd:int"/>
> > > </xsd:complexType>
> > >
> > > <xsd:complexType name="Parameters">
> > > <xsd:sequence>
> > > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > name="Parameter"
> > > type="config:Parameter"/>
> > > </xsd:sequence>
> > > <xsd:attribute name="List" type="xsd:string"/>
> > > </xsd:complexType>
> > >
> > > **Note** In <Parameters> Either List attribute OR Parameter element is
> > used
> > > BUT not both at a time. Attribut "List" is just to preserve existing
> > > convenience as in 3) A>
> > >
> > > 6) Existing test cases changes -
> > > No changes needed in existing xml configs
> > > Only 2 assertions changed in ProgrammaticConfigTests.
> > >
> > > 7) Exact code change and new test case details in JIRA-1462 comment
> > >
> > > Regards,
> > > Amita
> > >
> > > On 8/3/07, Adriano Crestani <ad...@apache.org> wrote:
> > > >
> > > > I agree with Amita that for clarity is better to let the user set
> the
> > > > parameter name, for all those reasons she has argued on this thread
> so
> > > > far.
> > > > But, I don't I agree with to use the [1] instead of [2], because
> it's
> > not
> > > > a
> > > > good practice to define the parameter names on only one string
> > separated
> > > > by
> > > > spaces, it's not a good practice, mainly when we're dealing with
> XML.
> > > >
> > > > My suggestion is to use [2], but add the <xsd:attribute name="name"
> > > > type="xsd:string"> on Parameter ComplexType and also keep the index
> > > > attribute on it. These way both methods, customer.set
> > ("pararmeterName",
> > > > "value") and customer.setParameter(parameterIndex, "value) will be
> > > > supported.
> > > >
> > > > However, on any of these cases, the user will need to define a
> > parameter N
> > > > times if there are N commands that use it. I don't see any solution
> > for
> > > > these case : (
> > > >
> > > > Regards,
> > > > Adriano Crestani
> > > >
> > > >
> > > > [1]<xsd:complexType name="Create">
> > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > <xsd:attribute name="parameters" type="xsd:string"/>
> > > > </xsd:complexType>
> > > >
> > > >
> > > > [2]<xsd:complexType name="Create">
> > > > <xsd:sequence>
> > > > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > > > name="Parameter"
> > > > type="config:Parameter"/>
> > > > </xsd:sequence>
> > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > </xsd:complexType>
> > > >
> > > >
> > > > On 8/2/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > > >
> > > > > JPQL, Hibernate ,... have support for named parameters.
> > > > >
> > > > > Why is RDB DAS going in the other way? If there is a reason for
> > > > switching
> > > > > off named parameters, please elaborate, else is it OK to go for
> > > > JIRA-1462?
> > > > >
> > > > > Regards,
> > > > > Amita
> > > > >
> > > > > On 7/13/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > > > >
> > > > > > I went through [1] and [2], it talks about removing name
> attribute
> > > > from
> > > > > > Parameter
> > > > > > and about generatedKeys. Also saw JIRA-528 on the way. But I
> could
> > not
> > > > > get
> > > > > > the exact
> > > > > > rational behind removing Name from Parameter (It is definitely
> not
> > > > > > required
> > > > > > by JDBC for sure, but can have some aid in usage clarity)....
> > > > > >
> > > > > > 1)One place in RDB DAS (here Name is not removed and can not be
> > > > removed)
> > > > > > BasicCustomerMappingWithCUD.xml (
> > > > > CRUDWithChangeHistory.testDeleteAndCreate
> > > > > > ())
> > > > > > <Config xmlns="http:///org.apache.tuscany.das.rdb/config.xsd">
> > > > > >
> > > > > > <Table tableName="CUSTOMER">
> > > > > > <create sql="insert into customer values (?, ?, ?)"
> > > > parameters="ID
> > > > > > LASTNAME ADDRESS"/>
> > > > > > <update sql="update customer set lastname = ?, address = ?
> > where
> > > > > ID
> > > > > > = ?" parameters="LASTNAME ADDRESS ID"/>
> > > > > > <delete sql="delete from customer where ID = ?"
> > > > parameters="ID"/>
> > > > > > </Table>
> > > > > >
> > > > > > </Config>
> > > > > >
> > > > > > This is informative because we have <create sql="insert into
> > customer
> > > > > > values (?, ?, ?)" parameters="ID LASTNAME ADDRESS"/>
> > > > > > In the client code we will typically have
> > > > > > DataObject customer = root.createDataObject("CUSTOMER");
> > > > > > customer.setInt("ID", 720);
> > > > > > customer.set("LASTNAME", "foobar");
> > > > > > customer.set("ADDRESS", "asdfasdf");
> > > > > >
> > > > > > das.applyChanges(root);
> > > > > >
> > > > > > Here client has a chance to understand that he needs to set ID,
> > > > > LASTNAME,
> > > > > > ADDRESS because the config states - parameters="ID LASTNAME
> > ADDRESS"
> > > > > and
> > > > > > internally we will map names to idx when doing
> > > > > > PreparedStatement.setParameter.
> > > > > >
> > > > > > For the matter of whether it is required to have parameters="ID
> > > > LASTNAME
> > > > > > ADDRESS" , it is required. We can no say parameters="1 2 3" or
> "X
> > Y
> > > > Z"
> > > > > > because during SDO to Parameter mapping (in ChangeOperation) we
> > need
> > > > > the
> > > > > > Name of parameter, so Name and Idx both are required.
> > > > > >
> > > > > > 2)Another place in RDB DAS (this is where Name is removed in
> > JIRA-658)
> > > > > > <Command name="InsertCustomers" SQL="insert into CUSTOMER
> > values
> > > > > > (?,?,?) " kind="Insert">
> > > > > > <Parameter direction="IN" index="1" columnType="
> > > > > commonj.sdo.IntObject
> > > > > > "/>
> > > > > > <Parameter direction="IN" index="2" columnType="
> > > > > commonj.sdo.String"/>
> > > > > >
> > > > > > <Parameter direction="IN" index="3" columnType="
> > > > > commonj.sdo.String"/>
> > > > > >
> > > > > > </Command>
> > > > > >
> > > > > > A typical client code will be,
> > > > > > Command insert = das.getCommand("InsertCustomers");
> > > > > > insert.setParameter(1, "1000");
> > > > > > insert.setParameter(2, "MYNAME");
> > > > > > insert.setParameter(3, "MYADDR");
> > > > > > insert.execute();
> > > > > >
> > > > > > In this example, nowhere the client has a way to know what 1000,
> > > > MYNAME
> > > > > or
> > > > > > MYADDRESS means. If this is a table with many columns and such
> > many
> > > > > tables,
> > > > > > how the client is going to set values using setParameter() with
> > any
> > > > > comfort
> > > > > > level, unless otherwise the he has a direct access to database
> and
> > can
> > > > > know
> > > > > > the names and order or columns in database table or if the
> insert
> > > > syntax
> > > > > is
> > > > > > used
> > > > > > like "insert into CUSTOMER (ID, LASTNAME, ADDRESS) values
> (?,?,?)
> > "
> > > > > >
> > > > > > but in tables having large number of rows, it is likely that
> > client
> > > > will
> > > > > > try to have short
> > > > > > (insert) statements without column names. And this is what I
> felt
> > was
> > > > > the
> > > > > > issue of the user in
> > > > > >
> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html,
> > > > as
> > > > > he
> > > > > > admitted that even though JDBC does not need Names, he needs it
> > for
> > > > the
> > > > > sake
> > > > > > of clarity.
> > > > > >
> > > > > > So, as such, first thig I am just curious to know is, what were
> > the
> > > > > > advantages of JIRA-658?
> > > > > >
> > > > > > Also, not quite clear about "Also, have you thought about
> multiple
> > > > > queries
> > > > > > retrieving the same column,you would have to configure the
> > parameter
> > > > in
> > > > > > multiple places." If there are 10 different Select Commands with
> > 10
> > > > > > different Where clauses, we anyway need to set Parameters in 10
> > > > > different
> > > > > > places.
> > > > > >
> > > > > > I guess I am completely intepreting something wrong here, please
> > help.
> > > > > >
> > > > > > Regards,
> > > > > > Amita
> > > > > >
> > > > > > On 7/13/07, Luciano Resende <lu...@gmail.com> wrote:
> > > > > > >
> > > > > > > The named parameter support was removed from earlier versions
> of
> > > > DAS,
> > > > > > > here is some previous discussion around the subject [1] See
> also
> > > > > > > tuscany-658. We might need to do further cleanup on the impl,
> if
> > I
> > > > > > > understood correctly.
> > > > > > >
> > > > > > > As for your second suggestion (parameter column types), could
> > you
> > > > > > > expose some use cases scenarios where this would be helpful ?
> > Also,
> > > > > > > have you thought about multiple queries retrieving the same
> > column,
> > > > > > > you would have to configure the parameter in multiple places.
> > > > > > >
> > > > > > > [1]
> > > > >
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04672.html
> > > > > > > [2] http://issues.apache.org/jira/browse/TUSCANY-658
> > > > > > >
> > > > > > > On 7/12/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > > > > > > Hi,
> > > > > > > > A few days ago there was a user question about passing name
> in
> > > > > > > Parameter:-
> > > > > > > >
> > > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html
> > > > > > > >
> > > > > > > > When checking how Parameters are used in Config, came across
> > the
> > > > > > > following
> > > > > > > > points.
> > > > > > > > There is a difference in Config (SDO) generated Parameter
> and
> > > > > > > > org.apache.tuscany.das.rdb.impl.ParameterImpl.
> > > > > > > >
> > > > > > > > The one from Config has only ColumnType, Direction and Index
> > > > whereas
> > > > > > > in
> > > > > > > > impl, it has
> > > > > > > > in addition Name and some other attributes. Not having Name
> in
> > > > > Config
> > > > > > > > generated version
> > > > > > > > does not cause any problems anywhere as JDBC
> PreparedStatement
> > > > > > > > setParameter() requires
> > > > > > > > Index and not Name. But to give a consistent user
> experience,
> > it
> > > > can
> > > > > > > be good
> > > > > > > > to add Name
> > > > > > > > (Optional).
> > > > > > > >
> > > > > > > > Also, when supporting <Create>, <Update>, <Delete> in RDB
> DAS
> > > > > Config,
> > > > > > > the
> > > > > > > > attribute
> > > > > > > > "parameters" is String, which is internally interpreted in
> > Index
> > > > and
> > > > > > > Name.
> > > > > > > > This misses
> > > > > > > > the ColumnType and Direction.Direction can be safely assumed
> > as IN
> > > > > for
> > > > > > > these
> > > > > > > > statements.
> > > > > > > > Also, not supplying ColumnType again causes no issues, as
> DAS
> > > > tries
> > > > > to
> > > > > > > get
> > > > > > > > it from database
> > > > > > > > metadata or using SDO standards. Still here again, if user
> can
> > > > > specify
> > > > > > > > ColumnType (optional),
> > > > > > > > it will give a consistent user experiece.
> > > > > > > >
> > > > > > > > So, question here, for the sake of consistency and uniform
> > user
> > > > > > > experience,
> > > > > > > > is it a good
> > > > > > > > idea to replace [1] with [2]? (Same for <Update> and
> <Delete>)
> > > > > > > >
> > > > > > > > [1]<xsd:complexType name="Create">
> > > > > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > > > > <xsd:attribute name="parameters"
> type="xsd:string"/>
> > > > > > > > </xsd:complexType>
> > > > > > > >
> > > > > > > >
> > > > > > > > [2]<xsd:complexType name="Create">
> > > > > > > > <xsd:sequence>
> > > > > > > > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > > > > > > name="Parameter"
> > > > > > > > type="config:Parameter"/>
> > > > > > > > </xsd:sequence>
> > > > > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > > > > </xsd:complexType>
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Amita
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Luciano Resende
> > > > > > > Apache Tuscany Committer
> > > > > > > http://people.apache.org/~lresende<
> > > > > http://people.apache.org/%7Elresende>
> > > > > > > http://lresende.blogspot.com/
> > > > > > >
> > > > > > >
> > > >
> ---------------------------------------------------------------------
> > > > > > > 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-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
>
Re: [RDB DAS] Consistent use of Parameters in Config
Posted by Amita Vadhavkar <am...@gmail.com>.
Thanks Kevin, for correcting the example, I actually meant what you have
assumed :)
Also, another question in JDK5 context, the code will be very precise and
type checking/assumptions about types can be avoided in many places in DAS
using JDK5 generics. Other features from JDK5 can be used too. So, I am just
curious to know the different
pros and cons about using JDK1.4 vs. using JDK5.
Regards,
Amita
On 8/30/07, Kevin Williams <kj...@gmail.com> wrote:
>
> This sounds good to me since programming model consistency is so very
> important. I agree that partial index specification should *not* be
> supported. I was concerned by your example:
>
> <Parameters>
> <Parameter name="ID" index="1"/> -- rest of the attributes optional
> <Parameter name="LASTNAME" /> -- rest of the attributes optional
> <Parameter name="ADDRESS" /> -- rest of the attributes optional
> </Parameters>
>
> But, i assume you meant
>
> <Parameters>
> <Parameter name="ID" index="1"/> -- rest of the attributes optional
> <Parameter name="LASTNAME" index="2"/> -- rest of the
> attributes optional
> <Parameter name="ADDRESS" index="3"/> -- rest of the attributes
> optional
> </Parameters>
>
> --Kevin
>
> On 8/29/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > Below is one of the use cases where user will get some benefit:-
> >
> > USE CASE:
> > bigtable{col1, col2,....col50}
> >
> > SIMPLEST CLIENT CODE: WITH NAMED PARAM SUPPORT
> > Command insertAdhoc = das.createCommand("insert into bigtable values (?,
> ?,
> > ?...50 times)");
> > insertAdhoc.setParameter("ID", new Integer(6));
> > insertAdhoc.setParameter("LASTNAME", "MyLastName");
> > insertAdhoc.setParameter("ADDRESS", "MyLastAddress");
> > ...
> > insertAdhoc.setParameter("Param50", "Value50");
> >
> > COMPARE WITH EXISTING WAY: WITHOUT NAMED PARAM SUPPORT
> > Command insertAdhoc = das.createCommand("insert into bigtable values (?,
> ?,
> > ?...50 times)");
> > insertAdhoc.setParameter(1, new Integer(6));
> > insertAdhoc.setParameter(2, "MyLastName");
> > insertAdhoc.setParameter(3, "MyLastAddress");
> > ...
> > insertAdhoc.setParameter(50, "Value50");
> >
> >
> ------------------------------------------------------------------------------------------------
> > Summary of previous discussion and main intention of this JIRA is to
> support
> > the below features:-
> > 1) Add attribute "Name" to parameter for user convenience/readability
> > 2) Support command.setParameter(name, value) for user
> > convenience/readability
> > 3) Preserve existing ways of using parameters - e.g.
> > A>
> > Continue supporting -
> > <Table tableName="CUSTOMER">
> > <create sql="insert into customer values (?, ?, ?)">
> > <Parameters List="ID LASTNAME ADDRESS"> </Parameters>
> > </create>
> > </Table>
> >
> > But also support -
> > <Table tableName="CUSTOMER">
> > <create sql="insert into customer values (?, ?, ?)" >
> > <Parameters>
> > <Parameter name="ID" index="1"/> -- rest of the attributes
> optional
> > <Parameter name="LASTNAME" /> -- rest of the attributes optional
> > <Parameter name="ADDRESS" /> -- rest of the attributes optional
> > </Parameters>
> > </create>
> > </Table>
> >
> > Note: if +ve index is specified in Parameter, it is used, else
> > auto-increment similar to A> is used. As List is an ordered collection,
> the
> > sequence appearing in the cofig file will be maintained. Partially
> > specifying indexes is not supported (i.e. give index for 2 out of 3
> params
> > and leave one without it, is not supported)
> >
> > B>
> > Continue supporting -
> > cmd.setParameter(1, new Integer(1)); cmd.getParameter(1);
> >
> > But also support -
> > cmd.setParameter("BOOKS.BOOK_ID", new Integer(1));
> > cmd.getParameter("BOOKS.BOOK_ID");
> >
> > C>
> > Continue supporting -
> > <Command...
> > <Parameter/>
> > <Parameter/>
> > </Command>
> >
> > And
> >
> > <Command..........No Params in Config, but directly
> setParameter(idx/name,
> > value) in program
> > </Command>
> >
> > But also support
> >
> > Command insertAdhoc = das.createCommand("insert into CUSTOMER values (?,
> ?,
> > ?)");
> > insertAdhoc.setParameter("ID", new Integer(6));
> > insertAdhoc.setParameter("LASTNAME", "MyLastName");
> > insertAdhoc.setParameter("ADDRESS", "MyLastAddress");
> >
> > Note: Convention over config is followed, if Parameters are not defined
> in
> > config, the sequence
> > should match the table columns [convention],else user should specify
> params
> > on command in config and specify index attributes in them [config]
> >
> > 4) This JIRA code will benefit a lot by use of JDK5 generics, but as DAS
> is
> > still at JDK1.4 level current code does not use generics.
> >
> > 5) Changes in config -
> > <xsd:complexType name="Create">
> > <xsd:sequence>
> > <xsd:element maxOccurs="1" minOccurs="0" name="Parameters"
> > type="config:Parameters"/>
> > </xsd:sequence>
> > <xsd:attribute name="sql" type="xsd:string"/>
> > </xsd:complexType>
> > ....Similar for Update and Delete.................
> >
> > <xsd:complexType name="Parameter">
> > <xsd:attribute name="name" type="xsd:string"/>
> > <xsd:attribute name="columnType" type="xsd:string"/>
> > <xsd:attribute name="direction" type="xsd:string" default="IN"/>
> > <xsd:attribute name="index" type="xsd:int"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="Parameters">
> > <xsd:sequence>
> > <xsd:element maxOccurs="unbounded" minOccurs="0"
> name="Parameter"
> > type="config:Parameter"/>
> > </xsd:sequence>
> > <xsd:attribute name="List" type="xsd:string"/>
> > </xsd:complexType>
> >
> > **Note** In <Parameters> Either List attribute OR Parameter element is
> used
> > BUT not both at a time. Attribut "List" is just to preserve existing
> > convenience as in 3) A>
> >
> > 6) Existing test cases changes -
> > No changes needed in existing xml configs
> > Only 2 assertions changed in ProgrammaticConfigTests.
> >
> > 7) Exact code change and new test case details in JIRA-1462 comment
> >
> > Regards,
> > Amita
> >
> > On 8/3/07, Adriano Crestani <ad...@apache.org> wrote:
> > >
> > > I agree with Amita that for clarity is better to let the user set the
> > > parameter name, for all those reasons she has argued on this thread so
> > > far.
> > > But, I don't I agree with to use the [1] instead of [2], because it's
> not
> > > a
> > > good practice to define the parameter names on only one string
> separated
> > > by
> > > spaces, it's not a good practice, mainly when we're dealing with XML.
> > >
> > > My suggestion is to use [2], but add the <xsd:attribute name="name"
> > > type="xsd:string"> on Parameter ComplexType and also keep the index
> > > attribute on it. These way both methods, customer.set
> ("pararmeterName",
> > > "value") and customer.setParameter(parameterIndex, "value) will be
> > > supported.
> > >
> > > However, on any of these cases, the user will need to define a
> parameter N
> > > times if there are N commands that use it. I don't see any solution
> for
> > > these case : (
> > >
> > > Regards,
> > > Adriano Crestani
> > >
> > >
> > > [1]<xsd:complexType name="Create">
> > > <xsd:attribute name="sql" type="xsd:string"/>
> > > <xsd:attribute name="parameters" type="xsd:string"/>
> > > </xsd:complexType>
> > >
> > >
> > > [2]<xsd:complexType name="Create">
> > > <xsd:sequence>
> > > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > > name="Parameter"
> > > type="config:Parameter"/>
> > > </xsd:sequence>
> > > <xsd:attribute name="sql" type="xsd:string"/>
> > > </xsd:complexType>
> > >
> > >
> > > On 8/2/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > >
> > > > JPQL, Hibernate ,... have support for named parameters.
> > > >
> > > > Why is RDB DAS going in the other way? If there is a reason for
> > > switching
> > > > off named parameters, please elaborate, else is it OK to go for
> > > JIRA-1462?
> > > >
> > > > Regards,
> > > > Amita
> > > >
> > > > On 7/13/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > > >
> > > > > I went through [1] and [2], it talks about removing name attribute
> > > from
> > > > > Parameter
> > > > > and about generatedKeys. Also saw JIRA-528 on the way. But I could
> not
> > > > get
> > > > > the exact
> > > > > rational behind removing Name from Parameter (It is definitely not
> > > > > required
> > > > > by JDBC for sure, but can have some aid in usage clarity)....
> > > > >
> > > > > 1)One place in RDB DAS (here Name is not removed and can not be
> > > removed)
> > > > > BasicCustomerMappingWithCUD.xml (
> > > > CRUDWithChangeHistory.testDeleteAndCreate
> > > > > ())
> > > > > <Config xmlns="http:///org.apache.tuscany.das.rdb/config.xsd">
> > > > >
> > > > > <Table tableName="CUSTOMER">
> > > > > <create sql="insert into customer values (?, ?, ?)"
> > > parameters="ID
> > > > > LASTNAME ADDRESS"/>
> > > > > <update sql="update customer set lastname = ?, address = ?
> where
> > > > ID
> > > > > = ?" parameters="LASTNAME ADDRESS ID"/>
> > > > > <delete sql="delete from customer where ID = ?"
> > > parameters="ID"/>
> > > > > </Table>
> > > > >
> > > > > </Config>
> > > > >
> > > > > This is informative because we have <create sql="insert into
> customer
> > > > > values (?, ?, ?)" parameters="ID LASTNAME ADDRESS"/>
> > > > > In the client code we will typically have
> > > > > DataObject customer = root.createDataObject("CUSTOMER");
> > > > > customer.setInt("ID", 720);
> > > > > customer.set("LASTNAME", "foobar");
> > > > > customer.set("ADDRESS", "asdfasdf");
> > > > >
> > > > > das.applyChanges(root);
> > > > >
> > > > > Here client has a chance to understand that he needs to set ID,
> > > > LASTNAME,
> > > > > ADDRESS because the config states - parameters="ID LASTNAME
> ADDRESS"
> > > > and
> > > > > internally we will map names to idx when doing
> > > > > PreparedStatement.setParameter.
> > > > >
> > > > > For the matter of whether it is required to have parameters="ID
> > > LASTNAME
> > > > > ADDRESS" , it is required. We can no say parameters="1 2 3" or "X
> Y
> > > Z"
> > > > > because during SDO to Parameter mapping (in ChangeOperation) we
> need
> > > > the
> > > > > Name of parameter, so Name and Idx both are required.
> > > > >
> > > > > 2)Another place in RDB DAS (this is where Name is removed in
> JIRA-658)
> > > > > <Command name="InsertCustomers" SQL="insert into CUSTOMER
> values
> > > > > (?,?,?) " kind="Insert">
> > > > > <Parameter direction="IN" index="1" columnType="
> > > > commonj.sdo.IntObject
> > > > > "/>
> > > > > <Parameter direction="IN" index="2" columnType="
> > > > commonj.sdo.String"/>
> > > > >
> > > > > <Parameter direction="IN" index="3" columnType="
> > > > commonj.sdo.String"/>
> > > > >
> > > > > </Command>
> > > > >
> > > > > A typical client code will be,
> > > > > Command insert = das.getCommand("InsertCustomers");
> > > > > insert.setParameter(1, "1000");
> > > > > insert.setParameter(2, "MYNAME");
> > > > > insert.setParameter(3, "MYADDR");
> > > > > insert.execute();
> > > > >
> > > > > In this example, nowhere the client has a way to know what 1000,
> > > MYNAME
> > > > or
> > > > > MYADDRESS means. If this is a table with many columns and such
> many
> > > > tables,
> > > > > how the client is going to set values using setParameter() with
> any
> > > > comfort
> > > > > level, unless otherwise the he has a direct access to database and
> can
> > > > know
> > > > > the names and order or columns in database table or if the insert
> > > syntax
> > > > is
> > > > > used
> > > > > like "insert into CUSTOMER (ID, LASTNAME, ADDRESS) values (?,?,?)
> "
> > > > >
> > > > > but in tables having large number of rows, it is likely that
> client
> > > will
> > > > > try to have short
> > > > > (insert) statements without column names. And this is what I felt
> was
> > > > the
> > > > > issue of the user in
> > > > >
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html,
> > > as
> > > > he
> > > > > admitted that even though JDBC does not need Names, he needs it
> for
> > > the
> > > > sake
> > > > > of clarity.
> > > > >
> > > > > So, as such, first thig I am just curious to know is, what were
> the
> > > > > advantages of JIRA-658?
> > > > >
> > > > > Also, not quite clear about "Also, have you thought about multiple
> > > > queries
> > > > > retrieving the same column,you would have to configure the
> parameter
> > > in
> > > > > multiple places." If there are 10 different Select Commands with
> 10
> > > > > different Where clauses, we anyway need to set Parameters in 10
> > > > different
> > > > > places.
> > > > >
> > > > > I guess I am completely intepreting something wrong here, please
> help.
> > > > >
> > > > > Regards,
> > > > > Amita
> > > > >
> > > > > On 7/13/07, Luciano Resende <lu...@gmail.com> wrote:
> > > > > >
> > > > > > The named parameter support was removed from earlier versions of
> > > DAS,
> > > > > > here is some previous discussion around the subject [1] See also
> > > > > > tuscany-658. We might need to do further cleanup on the impl, if
> I
> > > > > > understood correctly.
> > > > > >
> > > > > > As for your second suggestion (parameter column types), could
> you
> > > > > > expose some use cases scenarios where this would be helpful ?
> Also,
> > > > > > have you thought about multiple queries retrieving the same
> column,
> > > > > > you would have to configure the parameter in multiple places.
> > > > > >
> > > > > > [1]
> > > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04672.html
> > > > > > [2] http://issues.apache.org/jira/browse/TUSCANY-658
> > > > > >
> > > > > > On 7/12/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > > > > > Hi,
> > > > > > > A few days ago there was a user question about passing name in
> > > > > > Parameter:-
> > > > > > >
> > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html
> > > > > > >
> > > > > > > When checking how Parameters are used in Config, came across
> the
> > > > > > following
> > > > > > > points.
> > > > > > > There is a difference in Config (SDO) generated Parameter and
> > > > > > > org.apache.tuscany.das.rdb.impl.ParameterImpl.
> > > > > > >
> > > > > > > The one from Config has only ColumnType, Direction and Index
> > > whereas
> > > > > > in
> > > > > > > impl, it has
> > > > > > > in addition Name and some other attributes. Not having Name in
> > > > Config
> > > > > > > generated version
> > > > > > > does not cause any problems anywhere as JDBC PreparedStatement
> > > > > > > setParameter() requires
> > > > > > > Index and not Name. But to give a consistent user experience,
> it
> > > can
> > > > > > be good
> > > > > > > to add Name
> > > > > > > (Optional).
> > > > > > >
> > > > > > > Also, when supporting <Create>, <Update>, <Delete> in RDB DAS
> > > > Config,
> > > > > > the
> > > > > > > attribute
> > > > > > > "parameters" is String, which is internally interpreted in
> Index
> > > and
> > > > > > Name.
> > > > > > > This misses
> > > > > > > the ColumnType and Direction.Direction can be safely assumed
> as IN
> > > > for
> > > > > > these
> > > > > > > statements.
> > > > > > > Also, not supplying ColumnType again causes no issues, as DAS
> > > tries
> > > > to
> > > > > > get
> > > > > > > it from database
> > > > > > > metadata or using SDO standards. Still here again, if user can
> > > > specify
> > > > > > > ColumnType (optional),
> > > > > > > it will give a consistent user experiece.
> > > > > > >
> > > > > > > So, question here, for the sake of consistency and uniform
> user
> > > > > > experience,
> > > > > > > is it a good
> > > > > > > idea to replace [1] with [2]? (Same for <Update> and <Delete>)
> > > > > > >
> > > > > > > [1]<xsd:complexType name="Create">
> > > > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > > > <xsd:attribute name="parameters" type="xsd:string"/>
> > > > > > > </xsd:complexType>
> > > > > > >
> > > > > > >
> > > > > > > [2]<xsd:complexType name="Create">
> > > > > > > <xsd:sequence>
> > > > > > > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > > > > > name="Parameter"
> > > > > > > type="config:Parameter"/>
> > > > > > > </xsd:sequence>
> > > > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > > > </xsd:complexType>
> > > > > > >
> > > > > > > Regards,
> > > > > > > Amita
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Luciano Resende
> > > > > > Apache Tuscany Committer
> > > > > > http://people.apache.org/~lresende<
> > > > http://people.apache.org/%7Elresende>
> > > > > > http://lresende.blogspot.com/
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > 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-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Re: [RDB DAS] Consistent use of Parameters in Config
Posted by Amita Vadhavkar <am...@gmail.com>.
Thanks Kevin, for correcting the example, I actually meant what you have
assumed :)
Also, another question in JDK5 context, the code will be very precise and
type checking/assumptions about types can be avoided in many places in DAS
using JDK5 generics. Other features from JDK5 can be used too. So, I am just
curious to know the different
pros and cons about using JDK1.4 vs. using JDK5.
Regards,
Amita
On 8/30/07, Kevin Williams <kj...@gmail.com> wrote:
>
> This sounds good to me since programming model consistency is so very
> important. I agree that partial index specification should *not* be
> supported. I was concerned by your example:
>
> <Parameters>
> <Parameter name="ID" index="1"/> -- rest of the attributes optional
> <Parameter name="LASTNAME" /> -- rest of the attributes optional
> <Parameter name="ADDRESS" /> -- rest of the attributes optional
> </Parameters>
>
> But, i assume you meant
>
> <Parameters>
> <Parameter name="ID" index="1"/> -- rest of the attributes optional
> <Parameter name="LASTNAME" index="2"/> -- rest of the
> attributes optional
> <Parameter name="ADDRESS" index="3"/> -- rest of the attributes
> optional
> </Parameters>
>
> --Kevin
>
> On 8/29/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > Below is one of the use cases where user will get some benefit:-
> >
> > USE CASE:
> > bigtable{col1, col2,....col50}
> >
> > SIMPLEST CLIENT CODE: WITH NAMED PARAM SUPPORT
> > Command insertAdhoc = das.createCommand("insert into bigtable values (?,
> ?,
> > ?...50 times)");
> > insertAdhoc.setParameter("ID", new Integer(6));
> > insertAdhoc.setParameter("LASTNAME", "MyLastName");
> > insertAdhoc.setParameter("ADDRESS", "MyLastAddress");
> > ...
> > insertAdhoc.setParameter("Param50", "Value50");
> >
> > COMPARE WITH EXISTING WAY: WITHOUT NAMED PARAM SUPPORT
> > Command insertAdhoc = das.createCommand("insert into bigtable values (?,
> ?,
> > ?...50 times)");
> > insertAdhoc.setParameter(1, new Integer(6));
> > insertAdhoc.setParameter(2, "MyLastName");
> > insertAdhoc.setParameter(3, "MyLastAddress");
> > ...
> > insertAdhoc.setParameter(50, "Value50");
> >
> >
> ------------------------------------------------------------------------------------------------
> > Summary of previous discussion and main intention of this JIRA is to
> support
> > the below features:-
> > 1) Add attribute "Name" to parameter for user convenience/readability
> > 2) Support command.setParameter(name, value) for user
> > convenience/readability
> > 3) Preserve existing ways of using parameters - e.g.
> > A>
> > Continue supporting -
> > <Table tableName="CUSTOMER">
> > <create sql="insert into customer values (?, ?, ?)">
> > <Parameters List="ID LASTNAME ADDRESS"> </Parameters>
> > </create>
> > </Table>
> >
> > But also support -
> > <Table tableName="CUSTOMER">
> > <create sql="insert into customer values (?, ?, ?)" >
> > <Parameters>
> > <Parameter name="ID" index="1"/> -- rest of the attributes
> optional
> > <Parameter name="LASTNAME" /> -- rest of the attributes optional
> > <Parameter name="ADDRESS" /> -- rest of the attributes optional
> > </Parameters>
> > </create>
> > </Table>
> >
> > Note: if +ve index is specified in Parameter, it is used, else
> > auto-increment similar to A> is used. As List is an ordered collection,
> the
> > sequence appearing in the cofig file will be maintained. Partially
> > specifying indexes is not supported (i.e. give index for 2 out of 3
> params
> > and leave one without it, is not supported)
> >
> > B>
> > Continue supporting -
> > cmd.setParameter(1, new Integer(1)); cmd.getParameter(1);
> >
> > But also support -
> > cmd.setParameter("BOOKS.BOOK_ID", new Integer(1));
> > cmd.getParameter("BOOKS.BOOK_ID");
> >
> > C>
> > Continue supporting -
> > <Command...
> > <Parameter/>
> > <Parameter/>
> > </Command>
> >
> > And
> >
> > <Command..........No Params in Config, but directly
> setParameter(idx/name,
> > value) in program
> > </Command>
> >
> > But also support
> >
> > Command insertAdhoc = das.createCommand("insert into CUSTOMER values (?,
> ?,
> > ?)");
> > insertAdhoc.setParameter("ID", new Integer(6));
> > insertAdhoc.setParameter("LASTNAME", "MyLastName");
> > insertAdhoc.setParameter("ADDRESS", "MyLastAddress");
> >
> > Note: Convention over config is followed, if Parameters are not defined
> in
> > config, the sequence
> > should match the table columns [convention],else user should specify
> params
> > on command in config and specify index attributes in them [config]
> >
> > 4) This JIRA code will benefit a lot by use of JDK5 generics, but as DAS
> is
> > still at JDK1.4 level current code does not use generics.
> >
> > 5) Changes in config -
> > <xsd:complexType name="Create">
> > <xsd:sequence>
> > <xsd:element maxOccurs="1" minOccurs="0" name="Parameters"
> > type="config:Parameters"/>
> > </xsd:sequence>
> > <xsd:attribute name="sql" type="xsd:string"/>
> > </xsd:complexType>
> > ....Similar for Update and Delete.................
> >
> > <xsd:complexType name="Parameter">
> > <xsd:attribute name="name" type="xsd:string"/>
> > <xsd:attribute name="columnType" type="xsd:string"/>
> > <xsd:attribute name="direction" type="xsd:string" default="IN"/>
> > <xsd:attribute name="index" type="xsd:int"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="Parameters">
> > <xsd:sequence>
> > <xsd:element maxOccurs="unbounded" minOccurs="0"
> name="Parameter"
> > type="config:Parameter"/>
> > </xsd:sequence>
> > <xsd:attribute name="List" type="xsd:string"/>
> > </xsd:complexType>
> >
> > **Note** In <Parameters> Either List attribute OR Parameter element is
> used
> > BUT not both at a time. Attribut "List" is just to preserve existing
> > convenience as in 3) A>
> >
> > 6) Existing test cases changes -
> > No changes needed in existing xml configs
> > Only 2 assertions changed in ProgrammaticConfigTests.
> >
> > 7) Exact code change and new test case details in JIRA-1462 comment
> >
> > Regards,
> > Amita
> >
> > On 8/3/07, Adriano Crestani <ad...@apache.org> wrote:
> > >
> > > I agree with Amita that for clarity is better to let the user set the
> > > parameter name, for all those reasons she has argued on this thread so
> > > far.
> > > But, I don't I agree with to use the [1] instead of [2], because it's
> not
> > > a
> > > good practice to define the parameter names on only one string
> separated
> > > by
> > > spaces, it's not a good practice, mainly when we're dealing with XML.
> > >
> > > My suggestion is to use [2], but add the <xsd:attribute name="name"
> > > type="xsd:string"> on Parameter ComplexType and also keep the index
> > > attribute on it. These way both methods, customer.set
> ("pararmeterName",
> > > "value") and customer.setParameter(parameterIndex, "value) will be
> > > supported.
> > >
> > > However, on any of these cases, the user will need to define a
> parameter N
> > > times if there are N commands that use it. I don't see any solution
> for
> > > these case : (
> > >
> > > Regards,
> > > Adriano Crestani
> > >
> > >
> > > [1]<xsd:complexType name="Create">
> > > <xsd:attribute name="sql" type="xsd:string"/>
> > > <xsd:attribute name="parameters" type="xsd:string"/>
> > > </xsd:complexType>
> > >
> > >
> > > [2]<xsd:complexType name="Create">
> > > <xsd:sequence>
> > > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > > name="Parameter"
> > > type="config:Parameter"/>
> > > </xsd:sequence>
> > > <xsd:attribute name="sql" type="xsd:string"/>
> > > </xsd:complexType>
> > >
> > >
> > > On 8/2/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > >
> > > > JPQL, Hibernate ,... have support for named parameters.
> > > >
> > > > Why is RDB DAS going in the other way? If there is a reason for
> > > switching
> > > > off named parameters, please elaborate, else is it OK to go for
> > > JIRA-1462?
> > > >
> > > > Regards,
> > > > Amita
> > > >
> > > > On 7/13/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > > >
> > > > > I went through [1] and [2], it talks about removing name attribute
> > > from
> > > > > Parameter
> > > > > and about generatedKeys. Also saw JIRA-528 on the way. But I could
> not
> > > > get
> > > > > the exact
> > > > > rational behind removing Name from Parameter (It is definitely not
> > > > > required
> > > > > by JDBC for sure, but can have some aid in usage clarity)....
> > > > >
> > > > > 1)One place in RDB DAS (here Name is not removed and can not be
> > > removed)
> > > > > BasicCustomerMappingWithCUD.xml (
> > > > CRUDWithChangeHistory.testDeleteAndCreate
> > > > > ())
> > > > > <Config xmlns="http:///org.apache.tuscany.das.rdb/config.xsd">
> > > > >
> > > > > <Table tableName="CUSTOMER">
> > > > > <create sql="insert into customer values (?, ?, ?)"
> > > parameters="ID
> > > > > LASTNAME ADDRESS"/>
> > > > > <update sql="update customer set lastname = ?, address = ?
> where
> > > > ID
> > > > > = ?" parameters="LASTNAME ADDRESS ID"/>
> > > > > <delete sql="delete from customer where ID = ?"
> > > parameters="ID"/>
> > > > > </Table>
> > > > >
> > > > > </Config>
> > > > >
> > > > > This is informative because we have <create sql="insert into
> customer
> > > > > values (?, ?, ?)" parameters="ID LASTNAME ADDRESS"/>
> > > > > In the client code we will typically have
> > > > > DataObject customer = root.createDataObject("CUSTOMER");
> > > > > customer.setInt("ID", 720);
> > > > > customer.set("LASTNAME", "foobar");
> > > > > customer.set("ADDRESS", "asdfasdf");
> > > > >
> > > > > das.applyChanges(root);
> > > > >
> > > > > Here client has a chance to understand that he needs to set ID,
> > > > LASTNAME,
> > > > > ADDRESS because the config states - parameters="ID LASTNAME
> ADDRESS"
> > > > and
> > > > > internally we will map names to idx when doing
> > > > > PreparedStatement.setParameter.
> > > > >
> > > > > For the matter of whether it is required to have parameters="ID
> > > LASTNAME
> > > > > ADDRESS" , it is required. We can no say parameters="1 2 3" or "X
> Y
> > > Z"
> > > > > because during SDO to Parameter mapping (in ChangeOperation) we
> need
> > > > the
> > > > > Name of parameter, so Name and Idx both are required.
> > > > >
> > > > > 2)Another place in RDB DAS (this is where Name is removed in
> JIRA-658)
> > > > > <Command name="InsertCustomers" SQL="insert into CUSTOMER
> values
> > > > > (?,?,?) " kind="Insert">
> > > > > <Parameter direction="IN" index="1" columnType="
> > > > commonj.sdo.IntObject
> > > > > "/>
> > > > > <Parameter direction="IN" index="2" columnType="
> > > > commonj.sdo.String"/>
> > > > >
> > > > > <Parameter direction="IN" index="3" columnType="
> > > > commonj.sdo.String"/>
> > > > >
> > > > > </Command>
> > > > >
> > > > > A typical client code will be,
> > > > > Command insert = das.getCommand("InsertCustomers");
> > > > > insert.setParameter(1, "1000");
> > > > > insert.setParameter(2, "MYNAME");
> > > > > insert.setParameter(3, "MYADDR");
> > > > > insert.execute();
> > > > >
> > > > > In this example, nowhere the client has a way to know what 1000,
> > > MYNAME
> > > > or
> > > > > MYADDRESS means. If this is a table with many columns and such
> many
> > > > tables,
> > > > > how the client is going to set values using setParameter() with
> any
> > > > comfort
> > > > > level, unless otherwise the he has a direct access to database and
> can
> > > > know
> > > > > the names and order or columns in database table or if the insert
> > > syntax
> > > > is
> > > > > used
> > > > > like "insert into CUSTOMER (ID, LASTNAME, ADDRESS) values (?,?,?)
> "
> > > > >
> > > > > but in tables having large number of rows, it is likely that
> client
> > > will
> > > > > try to have short
> > > > > (insert) statements without column names. And this is what I felt
> was
> > > > the
> > > > > issue of the user in
> > > > >
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html,
> > > as
> > > > he
> > > > > admitted that even though JDBC does not need Names, he needs it
> for
> > > the
> > > > sake
> > > > > of clarity.
> > > > >
> > > > > So, as such, first thig I am just curious to know is, what were
> the
> > > > > advantages of JIRA-658?
> > > > >
> > > > > Also, not quite clear about "Also, have you thought about multiple
> > > > queries
> > > > > retrieving the same column,you would have to configure the
> parameter
> > > in
> > > > > multiple places." If there are 10 different Select Commands with
> 10
> > > > > different Where clauses, we anyway need to set Parameters in 10
> > > > different
> > > > > places.
> > > > >
> > > > > I guess I am completely intepreting something wrong here, please
> help.
> > > > >
> > > > > Regards,
> > > > > Amita
> > > > >
> > > > > On 7/13/07, Luciano Resende <lu...@gmail.com> wrote:
> > > > > >
> > > > > > The named parameter support was removed from earlier versions of
> > > DAS,
> > > > > > here is some previous discussion around the subject [1] See also
> > > > > > tuscany-658. We might need to do further cleanup on the impl, if
> I
> > > > > > understood correctly.
> > > > > >
> > > > > > As for your second suggestion (parameter column types), could
> you
> > > > > > expose some use cases scenarios where this would be helpful ?
> Also,
> > > > > > have you thought about multiple queries retrieving the same
> column,
> > > > > > you would have to configure the parameter in multiple places.
> > > > > >
> > > > > > [1]
> > > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04672.html
> > > > > > [2] http://issues.apache.org/jira/browse/TUSCANY-658
> > > > > >
> > > > > > On 7/12/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > > > > > Hi,
> > > > > > > A few days ago there was a user question about passing name in
> > > > > > Parameter:-
> > > > > > >
> > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html
> > > > > > >
> > > > > > > When checking how Parameters are used in Config, came across
> the
> > > > > > following
> > > > > > > points.
> > > > > > > There is a difference in Config (SDO) generated Parameter and
> > > > > > > org.apache.tuscany.das.rdb.impl.ParameterImpl.
> > > > > > >
> > > > > > > The one from Config has only ColumnType, Direction and Index
> > > whereas
> > > > > > in
> > > > > > > impl, it has
> > > > > > > in addition Name and some other attributes. Not having Name in
> > > > Config
> > > > > > > generated version
> > > > > > > does not cause any problems anywhere as JDBC PreparedStatement
> > > > > > > setParameter() requires
> > > > > > > Index and not Name. But to give a consistent user experience,
> it
> > > can
> > > > > > be good
> > > > > > > to add Name
> > > > > > > (Optional).
> > > > > > >
> > > > > > > Also, when supporting <Create>, <Update>, <Delete> in RDB DAS
> > > > Config,
> > > > > > the
> > > > > > > attribute
> > > > > > > "parameters" is String, which is internally interpreted in
> Index
> > > and
> > > > > > Name.
> > > > > > > This misses
> > > > > > > the ColumnType and Direction.Direction can be safely assumed
> as IN
> > > > for
> > > > > > these
> > > > > > > statements.
> > > > > > > Also, not supplying ColumnType again causes no issues, as DAS
> > > tries
> > > > to
> > > > > > get
> > > > > > > it from database
> > > > > > > metadata or using SDO standards. Still here again, if user can
> > > > specify
> > > > > > > ColumnType (optional),
> > > > > > > it will give a consistent user experiece.
> > > > > > >
> > > > > > > So, question here, for the sake of consistency and uniform
> user
> > > > > > experience,
> > > > > > > is it a good
> > > > > > > idea to replace [1] with [2]? (Same for <Update> and <Delete>)
> > > > > > >
> > > > > > > [1]<xsd:complexType name="Create">
> > > > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > > > <xsd:attribute name="parameters" type="xsd:string"/>
> > > > > > > </xsd:complexType>
> > > > > > >
> > > > > > >
> > > > > > > [2]<xsd:complexType name="Create">
> > > > > > > <xsd:sequence>
> > > > > > > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > > > > > name="Parameter"
> > > > > > > type="config:Parameter"/>
> > > > > > > </xsd:sequence>
> > > > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > > > </xsd:complexType>
> > > > > > >
> > > > > > > Regards,
> > > > > > > Amita
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Luciano Resende
> > > > > > Apache Tuscany Committer
> > > > > > http://people.apache.org/~lresende<
> > > > http://people.apache.org/%7Elresende>
> > > > > > http://lresende.blogspot.com/
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > 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-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Re: [RDB DAS] Consistent use of Parameters in Config
Posted by Kevin Williams <kj...@gmail.com>.
This sounds good to me since programming model consistency is so very
important. I agree that partial index specification should *not* be
supported. I was concerned by your example:
<Parameters>
<Parameter name="ID" index="1"/> -- rest of the attributes optional
<Parameter name="LASTNAME" /> -- rest of the attributes optional
<Parameter name="ADDRESS" /> -- rest of the attributes optional
</Parameters>
But, i assume you meant
<Parameters>
<Parameter name="ID" index="1"/> -- rest of the attributes optional
<Parameter name="LASTNAME" index="2"/> -- rest of the
attributes optional
<Parameter name="ADDRESS" index="3"/> -- rest of the attributes optional
</Parameters>
--Kevin
On 8/29/07, Amita Vadhavkar <am...@gmail.com> wrote:
> Below is one of the use cases where user will get some benefit:-
>
> USE CASE:
> bigtable{col1, col2,....col50}
>
> SIMPLEST CLIENT CODE: WITH NAMED PARAM SUPPORT
> Command insertAdhoc = das.createCommand("insert into bigtable values (?, ?,
> ?...50 times)");
> insertAdhoc.setParameter("ID", new Integer(6));
> insertAdhoc.setParameter("LASTNAME", "MyLastName");
> insertAdhoc.setParameter("ADDRESS", "MyLastAddress");
> ...
> insertAdhoc.setParameter("Param50", "Value50");
>
> COMPARE WITH EXISTING WAY: WITHOUT NAMED PARAM SUPPORT
> Command insertAdhoc = das.createCommand("insert into bigtable values (?, ?,
> ?...50 times)");
> insertAdhoc.setParameter(1, new Integer(6));
> insertAdhoc.setParameter(2, "MyLastName");
> insertAdhoc.setParameter(3, "MyLastAddress");
> ...
> insertAdhoc.setParameter(50, "Value50");
>
> ------------------------------------------------------------------------------------------------
> Summary of previous discussion and main intention of this JIRA is to support
> the below features:-
> 1) Add attribute "Name" to parameter for user convenience/readability
> 2) Support command.setParameter(name, value) for user
> convenience/readability
> 3) Preserve existing ways of using parameters - e.g.
> A>
> Continue supporting -
> <Table tableName="CUSTOMER">
> <create sql="insert into customer values (?, ?, ?)">
> <Parameters List="ID LASTNAME ADDRESS"> </Parameters>
> </create>
> </Table>
>
> But also support -
> <Table tableName="CUSTOMER">
> <create sql="insert into customer values (?, ?, ?)" >
> <Parameters>
> <Parameter name="ID" index="1"/> -- rest of the attributes optional
> <Parameter name="LASTNAME" /> -- rest of the attributes optional
> <Parameter name="ADDRESS" /> -- rest of the attributes optional
> </Parameters>
> </create>
> </Table>
>
> Note: if +ve index is specified in Parameter, it is used, else
> auto-increment similar to A> is used. As List is an ordered collection, the
> sequence appearing in the cofig file will be maintained. Partially
> specifying indexes is not supported (i.e. give index for 2 out of 3 params
> and leave one without it, is not supported)
>
> B>
> Continue supporting -
> cmd.setParameter(1, new Integer(1)); cmd.getParameter(1);
>
> But also support -
> cmd.setParameter("BOOKS.BOOK_ID", new Integer(1));
> cmd.getParameter("BOOKS.BOOK_ID");
>
> C>
> Continue supporting -
> <Command...
> <Parameter/>
> <Parameter/>
> </Command>
>
> And
>
> <Command..........No Params in Config, but directly setParameter(idx/name,
> value) in program
> </Command>
>
> But also support
>
> Command insertAdhoc = das.createCommand("insert into CUSTOMER values (?, ?,
> ?)");
> insertAdhoc.setParameter("ID", new Integer(6));
> insertAdhoc.setParameter("LASTNAME", "MyLastName");
> insertAdhoc.setParameter("ADDRESS", "MyLastAddress");
>
> Note: Convention over config is followed, if Parameters are not defined in
> config, the sequence
> should match the table columns [convention],else user should specify params
> on command in config and specify index attributes in them [config]
>
> 4) This JIRA code will benefit a lot by use of JDK5 generics, but as DAS is
> still at JDK1.4 level current code does not use generics.
>
> 5) Changes in config -
> <xsd:complexType name="Create">
> <xsd:sequence>
> <xsd:element maxOccurs="1" minOccurs="0" name="Parameters"
> type="config:Parameters"/>
> </xsd:sequence>
> <xsd:attribute name="sql" type="xsd:string"/>
> </xsd:complexType>
> ....Similar for Update and Delete.................
>
> <xsd:complexType name="Parameter">
> <xsd:attribute name="name" type="xsd:string"/>
> <xsd:attribute name="columnType" type="xsd:string"/>
> <xsd:attribute name="direction" type="xsd:string" default="IN"/>
> <xsd:attribute name="index" type="xsd:int"/>
> </xsd:complexType>
>
> <xsd:complexType name="Parameters">
> <xsd:sequence>
> <xsd:element maxOccurs="unbounded" minOccurs="0" name="Parameter"
> type="config:Parameter"/>
> </xsd:sequence>
> <xsd:attribute name="List" type="xsd:string"/>
> </xsd:complexType>
>
> **Note** In <Parameters> Either List attribute OR Parameter element is used
> BUT not both at a time. Attribut "List" is just to preserve existing
> convenience as in 3) A>
>
> 6) Existing test cases changes -
> No changes needed in existing xml configs
> Only 2 assertions changed in ProgrammaticConfigTests.
>
> 7) Exact code change and new test case details in JIRA-1462 comment
>
> Regards,
> Amita
>
> On 8/3/07, Adriano Crestani <ad...@apache.org> wrote:
> >
> > I agree with Amita that for clarity is better to let the user set the
> > parameter name, for all those reasons she has argued on this thread so
> > far.
> > But, I don't I agree with to use the [1] instead of [2], because it's not
> > a
> > good practice to define the parameter names on only one string separated
> > by
> > spaces, it's not a good practice, mainly when we're dealing with XML.
> >
> > My suggestion is to use [2], but add the <xsd:attribute name="name"
> > type="xsd:string"> on Parameter ComplexType and also keep the index
> > attribute on it. These way both methods, customer.set("pararmeterName",
> > "value") and customer.setParameter(parameterIndex, "value) will be
> > supported.
> >
> > However, on any of these cases, the user will need to define a parameter N
> > times if there are N commands that use it. I don't see any solution for
> > these case : (
> >
> > Regards,
> > Adriano Crestani
> >
> >
> > [1]<xsd:complexType name="Create">
> > <xsd:attribute name="sql" type="xsd:string"/>
> > <xsd:attribute name="parameters" type="xsd:string"/>
> > </xsd:complexType>
> >
> >
> > [2]<xsd:complexType name="Create">
> > <xsd:sequence>
> > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > name="Parameter"
> > type="config:Parameter"/>
> > </xsd:sequence>
> > <xsd:attribute name="sql" type="xsd:string"/>
> > </xsd:complexType>
> >
> >
> > On 8/2/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > >
> > > JPQL, Hibernate ,... have support for named parameters.
> > >
> > > Why is RDB DAS going in the other way? If there is a reason for
> > switching
> > > off named parameters, please elaborate, else is it OK to go for
> > JIRA-1462?
> > >
> > > Regards,
> > > Amita
> > >
> > > On 7/13/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > >
> > > > I went through [1] and [2], it talks about removing name attribute
> > from
> > > > Parameter
> > > > and about generatedKeys. Also saw JIRA-528 on the way. But I could not
> > > get
> > > > the exact
> > > > rational behind removing Name from Parameter (It is definitely not
> > > > required
> > > > by JDBC for sure, but can have some aid in usage clarity)....
> > > >
> > > > 1)One place in RDB DAS (here Name is not removed and can not be
> > removed)
> > > > BasicCustomerMappingWithCUD.xml (
> > > CRUDWithChangeHistory.testDeleteAndCreate
> > > > ())
> > > > <Config xmlns="http:///org.apache.tuscany.das.rdb/config.xsd">
> > > >
> > > > <Table tableName="CUSTOMER">
> > > > <create sql="insert into customer values (?, ?, ?)"
> > parameters="ID
> > > > LASTNAME ADDRESS"/>
> > > > <update sql="update customer set lastname = ?, address = ? where
> > > ID
> > > > = ?" parameters="LASTNAME ADDRESS ID"/>
> > > > <delete sql="delete from customer where ID = ?"
> > parameters="ID"/>
> > > > </Table>
> > > >
> > > > </Config>
> > > >
> > > > This is informative because we have <create sql="insert into customer
> > > > values (?, ?, ?)" parameters="ID LASTNAME ADDRESS"/>
> > > > In the client code we will typically have
> > > > DataObject customer = root.createDataObject("CUSTOMER");
> > > > customer.setInt("ID", 720);
> > > > customer.set("LASTNAME", "foobar");
> > > > customer.set("ADDRESS", "asdfasdf");
> > > >
> > > > das.applyChanges(root);
> > > >
> > > > Here client has a chance to understand that he needs to set ID,
> > > LASTNAME,
> > > > ADDRESS because the config states - parameters="ID LASTNAME ADDRESS"
> > > and
> > > > internally we will map names to idx when doing
> > > > PreparedStatement.setParameter.
> > > >
> > > > For the matter of whether it is required to have parameters="ID
> > LASTNAME
> > > > ADDRESS" , it is required. We can no say parameters="1 2 3" or "X Y
> > Z"
> > > > because during SDO to Parameter mapping (in ChangeOperation) we need
> > > the
> > > > Name of parameter, so Name and Idx both are required.
> > > >
> > > > 2)Another place in RDB DAS (this is where Name is removed in JIRA-658)
> > > > <Command name="InsertCustomers" SQL="insert into CUSTOMER values
> > > > (?,?,?) " kind="Insert">
> > > > <Parameter direction="IN" index="1" columnType="
> > > commonj.sdo.IntObject
> > > > "/>
> > > > <Parameter direction="IN" index="2" columnType="
> > > commonj.sdo.String"/>
> > > >
> > > > <Parameter direction="IN" index="3" columnType="
> > > commonj.sdo.String"/>
> > > >
> > > > </Command>
> > > >
> > > > A typical client code will be,
> > > > Command insert = das.getCommand("InsertCustomers");
> > > > insert.setParameter(1, "1000");
> > > > insert.setParameter(2, "MYNAME");
> > > > insert.setParameter(3, "MYADDR");
> > > > insert.execute();
> > > >
> > > > In this example, nowhere the client has a way to know what 1000,
> > MYNAME
> > > or
> > > > MYADDRESS means. If this is a table with many columns and such many
> > > tables,
> > > > how the client is going to set values using setParameter() with any
> > > comfort
> > > > level, unless otherwise the he has a direct access to database and can
> > > know
> > > > the names and order or columns in database table or if the insert
> > syntax
> > > is
> > > > used
> > > > like "insert into CUSTOMER (ID, LASTNAME, ADDRESS) values (?,?,?) "
> > > >
> > > > but in tables having large number of rows, it is likely that client
> > will
> > > > try to have short
> > > > (insert) statements without column names. And this is what I felt was
> > > the
> > > > issue of the user in
> > > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html,
> > as
> > > he
> > > > admitted that even though JDBC does not need Names, he needs it for
> > the
> > > sake
> > > > of clarity.
> > > >
> > > > So, as such, first thig I am just curious to know is, what were the
> > > > advantages of JIRA-658?
> > > >
> > > > Also, not quite clear about "Also, have you thought about multiple
> > > queries
> > > > retrieving the same column,you would have to configure the parameter
> > in
> > > > multiple places." If there are 10 different Select Commands with 10
> > > > different Where clauses, we anyway need to set Parameters in 10
> > > different
> > > > places.
> > > >
> > > > I guess I am completely intepreting something wrong here, please help.
> > > >
> > > > Regards,
> > > > Amita
> > > >
> > > > On 7/13/07, Luciano Resende <lu...@gmail.com> wrote:
> > > > >
> > > > > The named parameter support was removed from earlier versions of
> > DAS,
> > > > > here is some previous discussion around the subject [1] See also
> > > > > tuscany-658. We might need to do further cleanup on the impl, if I
> > > > > understood correctly.
> > > > >
> > > > > As for your second suggestion (parameter column types), could you
> > > > > expose some use cases scenarios where this would be helpful ? Also,
> > > > > have you thought about multiple queries retrieving the same column,
> > > > > you would have to configure the parameter in multiple places.
> > > > >
> > > > > [1]
> > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04672.html
> > > > > [2] http://issues.apache.org/jira/browse/TUSCANY-658
> > > > >
> > > > > On 7/12/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > > > > Hi,
> > > > > > A few days ago there was a user question about passing name in
> > > > > Parameter:-
> > > > > >
> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html
> > > > > >
> > > > > > When checking how Parameters are used in Config, came across the
> > > > > following
> > > > > > points.
> > > > > > There is a difference in Config (SDO) generated Parameter and
> > > > > > org.apache.tuscany.das.rdb.impl.ParameterImpl.
> > > > > >
> > > > > > The one from Config has only ColumnType, Direction and Index
> > whereas
> > > > > in
> > > > > > impl, it has
> > > > > > in addition Name and some other attributes. Not having Name in
> > > Config
> > > > > > generated version
> > > > > > does not cause any problems anywhere as JDBC PreparedStatement
> > > > > > setParameter() requires
> > > > > > Index and not Name. But to give a consistent user experience, it
> > can
> > > > > be good
> > > > > > to add Name
> > > > > > (Optional).
> > > > > >
> > > > > > Also, when supporting <Create>, <Update>, <Delete> in RDB DAS
> > > Config,
> > > > > the
> > > > > > attribute
> > > > > > "parameters" is String, which is internally interpreted in Index
> > and
> > > > > Name.
> > > > > > This misses
> > > > > > the ColumnType and Direction.Direction can be safely assumed as IN
> > > for
> > > > > these
> > > > > > statements.
> > > > > > Also, not supplying ColumnType again causes no issues, as DAS
> > tries
> > > to
> > > > > get
> > > > > > it from database
> > > > > > metadata or using SDO standards. Still here again, if user can
> > > specify
> > > > > > ColumnType (optional),
> > > > > > it will give a consistent user experiece.
> > > > > >
> > > > > > So, question here, for the sake of consistency and uniform user
> > > > > experience,
> > > > > > is it a good
> > > > > > idea to replace [1] with [2]? (Same for <Update> and <Delete>)
> > > > > >
> > > > > > [1]<xsd:complexType name="Create">
> > > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > > <xsd:attribute name="parameters" type="xsd:string"/>
> > > > > > </xsd:complexType>
> > > > > >
> > > > > >
> > > > > > [2]<xsd:complexType name="Create">
> > > > > > <xsd:sequence>
> > > > > > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > > > > name="Parameter"
> > > > > > type="config:Parameter"/>
> > > > > > </xsd:sequence>
> > > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > > </xsd:complexType>
> > > > > >
> > > > > > Regards,
> > > > > > Amita
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Luciano Resende
> > > > > Apache Tuscany Committer
> > > > > http://people.apache.org/~lresende<
> > > http://people.apache.org/%7Elresende>
> > > > > http://lresende.blogspot.com/
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > 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-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [RDB DAS] Consistent use of Parameters in Config
Posted by Amita Vadhavkar <am...@gmail.com>.
Below is one of the use cases where user will get some benefit:-
USE CASE:
bigtable{col1, col2,....col50}
SIMPLEST CLIENT CODE: WITH NAMED PARAM SUPPORT
Command insertAdhoc = das.createCommand("insert into bigtable values (?, ?,
?...50 times)");
insertAdhoc.setParameter("ID", new Integer(6));
insertAdhoc.setParameter("LASTNAME", "MyLastName");
insertAdhoc.setParameter("ADDRESS", "MyLastAddress");
...
insertAdhoc.setParameter("Param50", "Value50");
COMPARE WITH EXISTING WAY: WITHOUT NAMED PARAM SUPPORT
Command insertAdhoc = das.createCommand("insert into bigtable values (?, ?,
?...50 times)");
insertAdhoc.setParameter(1, new Integer(6));
insertAdhoc.setParameter(2, "MyLastName");
insertAdhoc.setParameter(3, "MyLastAddress");
...
insertAdhoc.setParameter(50, "Value50");
------------------------------------------------------------------------------------------------
Summary of previous discussion and main intention of this JIRA is to support
the below features:-
1) Add attribute "Name" to parameter for user convenience/readability
2) Support command.setParameter(name, value) for user
convenience/readability
3) Preserve existing ways of using parameters - e.g.
A>
Continue supporting -
<Table tableName="CUSTOMER">
<create sql="insert into customer values (?, ?, ?)">
<Parameters List="ID LASTNAME ADDRESS"> </Parameters>
</create>
</Table>
But also support -
<Table tableName="CUSTOMER">
<create sql="insert into customer values (?, ?, ?)" >
<Parameters>
<Parameter name="ID" index="1"/> -- rest of the attributes optional
<Parameter name="LASTNAME" /> -- rest of the attributes optional
<Parameter name="ADDRESS" /> -- rest of the attributes optional
</Parameters>
</create>
</Table>
Note: if +ve index is specified in Parameter, it is used, else
auto-increment similar to A> is used. As List is an ordered collection, the
sequence appearing in the cofig file will be maintained. Partially
specifying indexes is not supported (i.e. give index for 2 out of 3 params
and leave one without it, is not supported)
B>
Continue supporting -
cmd.setParameter(1, new Integer(1)); cmd.getParameter(1);
But also support -
cmd.setParameter("BOOKS.BOOK_ID", new Integer(1));
cmd.getParameter("BOOKS.BOOK_ID");
C>
Continue supporting -
<Command...
<Parameter/>
<Parameter/>
</Command>
And
<Command..........No Params in Config, but directly setParameter(idx/name,
value) in program
</Command>
But also support
Command insertAdhoc = das.createCommand("insert into CUSTOMER values (?, ?,
?)");
insertAdhoc.setParameter("ID", new Integer(6));
insertAdhoc.setParameter("LASTNAME", "MyLastName");
insertAdhoc.setParameter("ADDRESS", "MyLastAddress");
Note: Convention over config is followed, if Parameters are not defined in
config, the sequence
should match the table columns [convention],else user should specify params
on command in config and specify index attributes in them [config]
4) This JIRA code will benefit a lot by use of JDK5 generics, but as DAS is
still at JDK1.4 level current code does not use generics.
5) Changes in config -
<xsd:complexType name="Create">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" name="Parameters"
type="config:Parameters"/>
</xsd:sequence>
<xsd:attribute name="sql" type="xsd:string"/>
</xsd:complexType>
....Similar for Update and Delete.................
<xsd:complexType name="Parameter">
<xsd:attribute name="name" type="xsd:string"/>
<xsd:attribute name="columnType" type="xsd:string"/>
<xsd:attribute name="direction" type="xsd:string" default="IN"/>
<xsd:attribute name="index" type="xsd:int"/>
</xsd:complexType>
<xsd:complexType name="Parameters">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="Parameter"
type="config:Parameter"/>
</xsd:sequence>
<xsd:attribute name="List" type="xsd:string"/>
</xsd:complexType>
**Note** In <Parameters> Either List attribute OR Parameter element is used
BUT not both at a time. Attribut "List" is just to preserve existing
convenience as in 3) A>
6) Existing test cases changes -
No changes needed in existing xml configs
Only 2 assertions changed in ProgrammaticConfigTests.
7) Exact code change and new test case details in JIRA-1462 comment
Regards,
Amita
On 8/3/07, Adriano Crestani <ad...@apache.org> wrote:
>
> I agree with Amita that for clarity is better to let the user set the
> parameter name, for all those reasons she has argued on this thread so
> far.
> But, I don't I agree with to use the [1] instead of [2], because it's not
> a
> good practice to define the parameter names on only one string separated
> by
> spaces, it's not a good practice, mainly when we're dealing with XML.
>
> My suggestion is to use [2], but add the <xsd:attribute name="name"
> type="xsd:string"> on Parameter ComplexType and also keep the index
> attribute on it. These way both methods, customer.set("pararmeterName",
> "value") and customer.setParameter(parameterIndex, "value) will be
> supported.
>
> However, on any of these cases, the user will need to define a parameter N
> times if there are N commands that use it. I don't see any solution for
> these case : (
>
> Regards,
> Adriano Crestani
>
>
> [1]<xsd:complexType name="Create">
> <xsd:attribute name="sql" type="xsd:string"/>
> <xsd:attribute name="parameters" type="xsd:string"/>
> </xsd:complexType>
>
>
> [2]<xsd:complexType name="Create">
> <xsd:sequence>
> <xsd:element maxOccurs="unbounded" minOccurs="0"
> name="Parameter"
> type="config:Parameter"/>
> </xsd:sequence>
> <xsd:attribute name="sql" type="xsd:string"/>
> </xsd:complexType>
>
>
> On 8/2/07, Amita Vadhavkar <am...@gmail.com> wrote:
> >
> > JPQL, Hibernate ,... have support for named parameters.
> >
> > Why is RDB DAS going in the other way? If there is a reason for
> switching
> > off named parameters, please elaborate, else is it OK to go for
> JIRA-1462?
> >
> > Regards,
> > Amita
> >
> > On 7/13/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > >
> > > I went through [1] and [2], it talks about removing name attribute
> from
> > > Parameter
> > > and about generatedKeys. Also saw JIRA-528 on the way. But I could not
> > get
> > > the exact
> > > rational behind removing Name from Parameter (It is definitely not
> > > required
> > > by JDBC for sure, but can have some aid in usage clarity)....
> > >
> > > 1)One place in RDB DAS (here Name is not removed and can not be
> removed)
> > > BasicCustomerMappingWithCUD.xml (
> > CRUDWithChangeHistory.testDeleteAndCreate
> > > ())
> > > <Config xmlns="http:///org.apache.tuscany.das.rdb/config.xsd">
> > >
> > > <Table tableName="CUSTOMER">
> > > <create sql="insert into customer values (?, ?, ?)"
> parameters="ID
> > > LASTNAME ADDRESS"/>
> > > <update sql="update customer set lastname = ?, address = ? where
> > ID
> > > = ?" parameters="LASTNAME ADDRESS ID"/>
> > > <delete sql="delete from customer where ID = ?"
> parameters="ID"/>
> > > </Table>
> > >
> > > </Config>
> > >
> > > This is informative because we have <create sql="insert into customer
> > > values (?, ?, ?)" parameters="ID LASTNAME ADDRESS"/>
> > > In the client code we will typically have
> > > DataObject customer = root.createDataObject("CUSTOMER");
> > > customer.setInt("ID", 720);
> > > customer.set("LASTNAME", "foobar");
> > > customer.set("ADDRESS", "asdfasdf");
> > >
> > > das.applyChanges(root);
> > >
> > > Here client has a chance to understand that he needs to set ID,
> > LASTNAME,
> > > ADDRESS because the config states - parameters="ID LASTNAME ADDRESS"
> > and
> > > internally we will map names to idx when doing
> > > PreparedStatement.setParameter.
> > >
> > > For the matter of whether it is required to have parameters="ID
> LASTNAME
> > > ADDRESS" , it is required. We can no say parameters="1 2 3" or "X Y
> Z"
> > > because during SDO to Parameter mapping (in ChangeOperation) we need
> > the
> > > Name of parameter, so Name and Idx both are required.
> > >
> > > 2)Another place in RDB DAS (this is where Name is removed in JIRA-658)
> > > <Command name="InsertCustomers" SQL="insert into CUSTOMER values
> > > (?,?,?) " kind="Insert">
> > > <Parameter direction="IN" index="1" columnType="
> > commonj.sdo.IntObject
> > > "/>
> > > <Parameter direction="IN" index="2" columnType="
> > commonj.sdo.String"/>
> > >
> > > <Parameter direction="IN" index="3" columnType="
> > commonj.sdo.String"/>
> > >
> > > </Command>
> > >
> > > A typical client code will be,
> > > Command insert = das.getCommand("InsertCustomers");
> > > insert.setParameter(1, "1000");
> > > insert.setParameter(2, "MYNAME");
> > > insert.setParameter(3, "MYADDR");
> > > insert.execute();
> > >
> > > In this example, nowhere the client has a way to know what 1000,
> MYNAME
> > or
> > > MYADDRESS means. If this is a table with many columns and such many
> > tables,
> > > how the client is going to set values using setParameter() with any
> > comfort
> > > level, unless otherwise the he has a direct access to database and can
> > know
> > > the names and order or columns in database table or if the insert
> syntax
> > is
> > > used
> > > like "insert into CUSTOMER (ID, LASTNAME, ADDRESS) values (?,?,?) "
> > >
> > > but in tables having large number of rows, it is likely that client
> will
> > > try to have short
> > > (insert) statements without column names. And this is what I felt was
> > the
> > > issue of the user in
> > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html,
> as
> > he
> > > admitted that even though JDBC does not need Names, he needs it for
> the
> > sake
> > > of clarity.
> > >
> > > So, as such, first thig I am just curious to know is, what were the
> > > advantages of JIRA-658?
> > >
> > > Also, not quite clear about "Also, have you thought about multiple
> > queries
> > > retrieving the same column,you would have to configure the parameter
> in
> > > multiple places." If there are 10 different Select Commands with 10
> > > different Where clauses, we anyway need to set Parameters in 10
> > different
> > > places.
> > >
> > > I guess I am completely intepreting something wrong here, please help.
> > >
> > > Regards,
> > > Amita
> > >
> > > On 7/13/07, Luciano Resende <lu...@gmail.com> wrote:
> > > >
> > > > The named parameter support was removed from earlier versions of
> DAS,
> > > > here is some previous discussion around the subject [1] See also
> > > > tuscany-658. We might need to do further cleanup on the impl, if I
> > > > understood correctly.
> > > >
> > > > As for your second suggestion (parameter column types), could you
> > > > expose some use cases scenarios where this would be helpful ? Also,
> > > > have you thought about multiple queries retrieving the same column,
> > > > you would have to configure the parameter in multiple places.
> > > >
> > > > [1]
> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04672.html
> > > > [2] http://issues.apache.org/jira/browse/TUSCANY-658
> > > >
> > > > On 7/12/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > > > Hi,
> > > > > A few days ago there was a user question about passing name in
> > > > Parameter:-
> > > > >
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html
> > > > >
> > > > > When checking how Parameters are used in Config, came across the
> > > > following
> > > > > points.
> > > > > There is a difference in Config (SDO) generated Parameter and
> > > > > org.apache.tuscany.das.rdb.impl.ParameterImpl.
> > > > >
> > > > > The one from Config has only ColumnType, Direction and Index
> whereas
> > > > in
> > > > > impl, it has
> > > > > in addition Name and some other attributes. Not having Name in
> > Config
> > > > > generated version
> > > > > does not cause any problems anywhere as JDBC PreparedStatement
> > > > > setParameter() requires
> > > > > Index and not Name. But to give a consistent user experience, it
> can
> > > > be good
> > > > > to add Name
> > > > > (Optional).
> > > > >
> > > > > Also, when supporting <Create>, <Update>, <Delete> in RDB DAS
> > Config,
> > > > the
> > > > > attribute
> > > > > "parameters" is String, which is internally interpreted in Index
> and
> > > > Name.
> > > > > This misses
> > > > > the ColumnType and Direction.Direction can be safely assumed as IN
> > for
> > > > these
> > > > > statements.
> > > > > Also, not supplying ColumnType again causes no issues, as DAS
> tries
> > to
> > > > get
> > > > > it from database
> > > > > metadata or using SDO standards. Still here again, if user can
> > specify
> > > > > ColumnType (optional),
> > > > > it will give a consistent user experiece.
> > > > >
> > > > > So, question here, for the sake of consistency and uniform user
> > > > experience,
> > > > > is it a good
> > > > > idea to replace [1] with [2]? (Same for <Update> and <Delete>)
> > > > >
> > > > > [1]<xsd:complexType name="Create">
> > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > <xsd:attribute name="parameters" type="xsd:string"/>
> > > > > </xsd:complexType>
> > > > >
> > > > >
> > > > > [2]<xsd:complexType name="Create">
> > > > > <xsd:sequence>
> > > > > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > > > name="Parameter"
> > > > > type="config:Parameter"/>
> > > > > </xsd:sequence>
> > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > </xsd:complexType>
> > > > >
> > > > > Regards,
> > > > > Amita
> > > > >
> > > >
> > > >
> > > > --
> > > > Luciano Resende
> > > > Apache Tuscany Committer
> > > > http://people.apache.org/~lresende<
> > http://people.apache.org/%7Elresende>
> > > > http://lresende.blogspot.com/
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> >
>
Re: [RDB DAS] Consistent use of Parameters in Config
Posted by Amita Vadhavkar <am...@gmail.com>.
Below is one of the use cases where user will get some benefit:-
USE CASE:
bigtable{col1, col2,....col50}
SIMPLEST CLIENT CODE: WITH NAMED PARAM SUPPORT
Command insertAdhoc = das.createCommand("insert into bigtable values (?, ?,
?...50 times)");
insertAdhoc.setParameter("ID", new Integer(6));
insertAdhoc.setParameter("LASTNAME", "MyLastName");
insertAdhoc.setParameter("ADDRESS", "MyLastAddress");
...
insertAdhoc.setParameter("Param50", "Value50");
COMPARE WITH EXISTING WAY: WITHOUT NAMED PARAM SUPPORT
Command insertAdhoc = das.createCommand("insert into bigtable values (?, ?,
?...50 times)");
insertAdhoc.setParameter(1, new Integer(6));
insertAdhoc.setParameter(2, "MyLastName");
insertAdhoc.setParameter(3, "MyLastAddress");
...
insertAdhoc.setParameter(50, "Value50");
------------------------------------------------------------------------------------------------
Summary of previous discussion and main intention of this JIRA is to support
the below features:-
1) Add attribute "Name" to parameter for user convenience/readability
2) Support command.setParameter(name, value) for user
convenience/readability
3) Preserve existing ways of using parameters - e.g.
A>
Continue supporting -
<Table tableName="CUSTOMER">
<create sql="insert into customer values (?, ?, ?)">
<Parameters List="ID LASTNAME ADDRESS"> </Parameters>
</create>
</Table>
But also support -
<Table tableName="CUSTOMER">
<create sql="insert into customer values (?, ?, ?)" >
<Parameters>
<Parameter name="ID" index="1"/> -- rest of the attributes optional
<Parameter name="LASTNAME" /> -- rest of the attributes optional
<Parameter name="ADDRESS" /> -- rest of the attributes optional
</Parameters>
</create>
</Table>
Note: if +ve index is specified in Parameter, it is used, else
auto-increment similar to A> is used. As List is an ordered collection, the
sequence appearing in the cofig file will be maintained. Partially
specifying indexes is not supported (i.e. give index for 2 out of 3 params
and leave one without it, is not supported)
B>
Continue supporting -
cmd.setParameter(1, new Integer(1)); cmd.getParameter(1);
But also support -
cmd.setParameter("BOOKS.BOOK_ID", new Integer(1));
cmd.getParameter("BOOKS.BOOK_ID");
C>
Continue supporting -
<Command...
<Parameter/>
<Parameter/>
</Command>
And
<Command..........No Params in Config, but directly setParameter(idx/name,
value) in program
</Command>
But also support
Command insertAdhoc = das.createCommand("insert into CUSTOMER values (?, ?,
?)");
insertAdhoc.setParameter("ID", new Integer(6));
insertAdhoc.setParameter("LASTNAME", "MyLastName");
insertAdhoc.setParameter("ADDRESS", "MyLastAddress");
Note: Convention over config is followed, if Parameters are not defined in
config, the sequence
should match the table columns [convention],else user should specify params
on command in config and specify index attributes in them [config]
4) This JIRA code will benefit a lot by use of JDK5 generics, but as DAS is
still at JDK1.4 level current code does not use generics.
5) Changes in config -
<xsd:complexType name="Create">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" name="Parameters"
type="config:Parameters"/>
</xsd:sequence>
<xsd:attribute name="sql" type="xsd:string"/>
</xsd:complexType>
....Similar for Update and Delete.................
<xsd:complexType name="Parameter">
<xsd:attribute name="name" type="xsd:string"/>
<xsd:attribute name="columnType" type="xsd:string"/>
<xsd:attribute name="direction" type="xsd:string" default="IN"/>
<xsd:attribute name="index" type="xsd:int"/>
</xsd:complexType>
<xsd:complexType name="Parameters">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="Parameter"
type="config:Parameter"/>
</xsd:sequence>
<xsd:attribute name="List" type="xsd:string"/>
</xsd:complexType>
**Note** In <Parameters> Either List attribute OR Parameter element is used
BUT not both at a time. Attribut "List" is just to preserve existing
convenience as in 3) A>
6) Existing test cases changes -
No changes needed in existing xml configs
Only 2 assertions changed in ProgrammaticConfigTests.
7) Exact code change and new test case details in JIRA-1462 comment
Regards,
Amita
On 8/3/07, Adriano Crestani <ad...@apache.org> wrote:
>
> I agree with Amita that for clarity is better to let the user set the
> parameter name, for all those reasons she has argued on this thread so
> far.
> But, I don't I agree with to use the [1] instead of [2], because it's not
> a
> good practice to define the parameter names on only one string separated
> by
> spaces, it's not a good practice, mainly when we're dealing with XML.
>
> My suggestion is to use [2], but add the <xsd:attribute name="name"
> type="xsd:string"> on Parameter ComplexType and also keep the index
> attribute on it. These way both methods, customer.set("pararmeterName",
> "value") and customer.setParameter(parameterIndex, "value) will be
> supported.
>
> However, on any of these cases, the user will need to define a parameter N
> times if there are N commands that use it. I don't see any solution for
> these case : (
>
> Regards,
> Adriano Crestani
>
>
> [1]<xsd:complexType name="Create">
> <xsd:attribute name="sql" type="xsd:string"/>
> <xsd:attribute name="parameters" type="xsd:string"/>
> </xsd:complexType>
>
>
> [2]<xsd:complexType name="Create">
> <xsd:sequence>
> <xsd:element maxOccurs="unbounded" minOccurs="0"
> name="Parameter"
> type="config:Parameter"/>
> </xsd:sequence>
> <xsd:attribute name="sql" type="xsd:string"/>
> </xsd:complexType>
>
>
> On 8/2/07, Amita Vadhavkar <am...@gmail.com> wrote:
> >
> > JPQL, Hibernate ,... have support for named parameters.
> >
> > Why is RDB DAS going in the other way? If there is a reason for
> switching
> > off named parameters, please elaborate, else is it OK to go for
> JIRA-1462?
> >
> > Regards,
> > Amita
> >
> > On 7/13/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > >
> > > I went through [1] and [2], it talks about removing name attribute
> from
> > > Parameter
> > > and about generatedKeys. Also saw JIRA-528 on the way. But I could not
> > get
> > > the exact
> > > rational behind removing Name from Parameter (It is definitely not
> > > required
> > > by JDBC for sure, but can have some aid in usage clarity)....
> > >
> > > 1)One place in RDB DAS (here Name is not removed and can not be
> removed)
> > > BasicCustomerMappingWithCUD.xml (
> > CRUDWithChangeHistory.testDeleteAndCreate
> > > ())
> > > <Config xmlns="http:///org.apache.tuscany.das.rdb/config.xsd">
> > >
> > > <Table tableName="CUSTOMER">
> > > <create sql="insert into customer values (?, ?, ?)"
> parameters="ID
> > > LASTNAME ADDRESS"/>
> > > <update sql="update customer set lastname = ?, address = ? where
> > ID
> > > = ?" parameters="LASTNAME ADDRESS ID"/>
> > > <delete sql="delete from customer where ID = ?"
> parameters="ID"/>
> > > </Table>
> > >
> > > </Config>
> > >
> > > This is informative because we have <create sql="insert into customer
> > > values (?, ?, ?)" parameters="ID LASTNAME ADDRESS"/>
> > > In the client code we will typically have
> > > DataObject customer = root.createDataObject("CUSTOMER");
> > > customer.setInt("ID", 720);
> > > customer.set("LASTNAME", "foobar");
> > > customer.set("ADDRESS", "asdfasdf");
> > >
> > > das.applyChanges(root);
> > >
> > > Here client has a chance to understand that he needs to set ID,
> > LASTNAME,
> > > ADDRESS because the config states - parameters="ID LASTNAME ADDRESS"
> > and
> > > internally we will map names to idx when doing
> > > PreparedStatement.setParameter.
> > >
> > > For the matter of whether it is required to have parameters="ID
> LASTNAME
> > > ADDRESS" , it is required. We can no say parameters="1 2 3" or "X Y
> Z"
> > > because during SDO to Parameter mapping (in ChangeOperation) we need
> > the
> > > Name of parameter, so Name and Idx both are required.
> > >
> > > 2)Another place in RDB DAS (this is where Name is removed in JIRA-658)
> > > <Command name="InsertCustomers" SQL="insert into CUSTOMER values
> > > (?,?,?) " kind="Insert">
> > > <Parameter direction="IN" index="1" columnType="
> > commonj.sdo.IntObject
> > > "/>
> > > <Parameter direction="IN" index="2" columnType="
> > commonj.sdo.String"/>
> > >
> > > <Parameter direction="IN" index="3" columnType="
> > commonj.sdo.String"/>
> > >
> > > </Command>
> > >
> > > A typical client code will be,
> > > Command insert = das.getCommand("InsertCustomers");
> > > insert.setParameter(1, "1000");
> > > insert.setParameter(2, "MYNAME");
> > > insert.setParameter(3, "MYADDR");
> > > insert.execute();
> > >
> > > In this example, nowhere the client has a way to know what 1000,
> MYNAME
> > or
> > > MYADDRESS means. If this is a table with many columns and such many
> > tables,
> > > how the client is going to set values using setParameter() with any
> > comfort
> > > level, unless otherwise the he has a direct access to database and can
> > know
> > > the names and order or columns in database table or if the insert
> syntax
> > is
> > > used
> > > like "insert into CUSTOMER (ID, LASTNAME, ADDRESS) values (?,?,?) "
> > >
> > > but in tables having large number of rows, it is likely that client
> will
> > > try to have short
> > > (insert) statements without column names. And this is what I felt was
> > the
> > > issue of the user in
> > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html,
> as
> > he
> > > admitted that even though JDBC does not need Names, he needs it for
> the
> > sake
> > > of clarity.
> > >
> > > So, as such, first thig I am just curious to know is, what were the
> > > advantages of JIRA-658?
> > >
> > > Also, not quite clear about "Also, have you thought about multiple
> > queries
> > > retrieving the same column,you would have to configure the parameter
> in
> > > multiple places." If there are 10 different Select Commands with 10
> > > different Where clauses, we anyway need to set Parameters in 10
> > different
> > > places.
> > >
> > > I guess I am completely intepreting something wrong here, please help.
> > >
> > > Regards,
> > > Amita
> > >
> > > On 7/13/07, Luciano Resende <lu...@gmail.com> wrote:
> > > >
> > > > The named parameter support was removed from earlier versions of
> DAS,
> > > > here is some previous discussion around the subject [1] See also
> > > > tuscany-658. We might need to do further cleanup on the impl, if I
> > > > understood correctly.
> > > >
> > > > As for your second suggestion (parameter column types), could you
> > > > expose some use cases scenarios where this would be helpful ? Also,
> > > > have you thought about multiple queries retrieving the same column,
> > > > you would have to configure the parameter in multiple places.
> > > >
> > > > [1]
> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04672.html
> > > > [2] http://issues.apache.org/jira/browse/TUSCANY-658
> > > >
> > > > On 7/12/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > > > Hi,
> > > > > A few days ago there was a user question about passing name in
> > > > Parameter:-
> > > > >
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html
> > > > >
> > > > > When checking how Parameters are used in Config, came across the
> > > > following
> > > > > points.
> > > > > There is a difference in Config (SDO) generated Parameter and
> > > > > org.apache.tuscany.das.rdb.impl.ParameterImpl.
> > > > >
> > > > > The one from Config has only ColumnType, Direction and Index
> whereas
> > > > in
> > > > > impl, it has
> > > > > in addition Name and some other attributes. Not having Name in
> > Config
> > > > > generated version
> > > > > does not cause any problems anywhere as JDBC PreparedStatement
> > > > > setParameter() requires
> > > > > Index and not Name. But to give a consistent user experience, it
> can
> > > > be good
> > > > > to add Name
> > > > > (Optional).
> > > > >
> > > > > Also, when supporting <Create>, <Update>, <Delete> in RDB DAS
> > Config,
> > > > the
> > > > > attribute
> > > > > "parameters" is String, which is internally interpreted in Index
> and
> > > > Name.
> > > > > This misses
> > > > > the ColumnType and Direction.Direction can be safely assumed as IN
> > for
> > > > these
> > > > > statements.
> > > > > Also, not supplying ColumnType again causes no issues, as DAS
> tries
> > to
> > > > get
> > > > > it from database
> > > > > metadata or using SDO standards. Still here again, if user can
> > specify
> > > > > ColumnType (optional),
> > > > > it will give a consistent user experiece.
> > > > >
> > > > > So, question here, for the sake of consistency and uniform user
> > > > experience,
> > > > > is it a good
> > > > > idea to replace [1] with [2]? (Same for <Update> and <Delete>)
> > > > >
> > > > > [1]<xsd:complexType name="Create">
> > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > <xsd:attribute name="parameters" type="xsd:string"/>
> > > > > </xsd:complexType>
> > > > >
> > > > >
> > > > > [2]<xsd:complexType name="Create">
> > > > > <xsd:sequence>
> > > > > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > > > name="Parameter"
> > > > > type="config:Parameter"/>
> > > > > </xsd:sequence>
> > > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > > </xsd:complexType>
> > > > >
> > > > > Regards,
> > > > > Amita
> > > > >
> > > >
> > > >
> > > > --
> > > > Luciano Resende
> > > > Apache Tuscany Committer
> > > > http://people.apache.org/~lresende<
> > http://people.apache.org/%7Elresende>
> > > > http://lresende.blogspot.com/
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> >
>
Re: [RDB DAS] Consistent use of Parameters in Config
Posted by Adriano Crestani <ad...@apache.org>.
I agree with Amita that for clarity is better to let the user set the
parameter name, for all those reasons she has argued on this thread so far.
But, I don't I agree with to use the [1] instead of [2], because it's not a
good practice to define the parameter names on only one string separated by
spaces, it's not a good practice, mainly when we're dealing with XML.
My suggestion is to use [2], but add the <xsd:attribute name="name"
type="xsd:string"> on Parameter ComplexType and also keep the index
attribute on it. These way both methods, customer.set("pararmeterName",
"value") and customer.setParameter(parameterIndex, "value) will be
supported.
However, on any of these cases, the user will need to define a parameter N
times if there are N commands that use it. I don't see any solution for
these case : (
Regards,
Adriano Crestani
[1]<xsd:complexType name="Create">
<xsd:attribute name="sql" type="xsd:string"/>
<xsd:attribute name="parameters" type="xsd:string"/>
</xsd:complexType>
[2]<xsd:complexType name="Create">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="Parameter"
type="config:Parameter"/>
</xsd:sequence>
<xsd:attribute name="sql" type="xsd:string"/>
</xsd:complexType>
On 8/2/07, Amita Vadhavkar <am...@gmail.com> wrote:
>
> JPQL, Hibernate ,... have support for named parameters.
>
> Why is RDB DAS going in the other way? If there is a reason for switching
> off named parameters, please elaborate, else is it OK to go for JIRA-1462?
>
> Regards,
> Amita
>
> On 7/13/07, Amita Vadhavkar <am...@gmail.com> wrote:
> >
> > I went through [1] and [2], it talks about removing name attribute from
> > Parameter
> > and about generatedKeys. Also saw JIRA-528 on the way. But I could not
> get
> > the exact
> > rational behind removing Name from Parameter (It is definitely not
> > required
> > by JDBC for sure, but can have some aid in usage clarity)....
> >
> > 1)One place in RDB DAS (here Name is not removed and can not be removed)
> > BasicCustomerMappingWithCUD.xml (
> CRUDWithChangeHistory.testDeleteAndCreate
> > ())
> > <Config xmlns="http:///org.apache.tuscany.das.rdb/config.xsd">
> >
> > <Table tableName="CUSTOMER">
> > <create sql="insert into customer values (?, ?, ?)" parameters="ID
> > LASTNAME ADDRESS"/>
> > <update sql="update customer set lastname = ?, address = ? where
> ID
> > = ?" parameters="LASTNAME ADDRESS ID"/>
> > <delete sql="delete from customer where ID = ?" parameters="ID"/>
> > </Table>
> >
> > </Config>
> >
> > This is informative because we have <create sql="insert into customer
> > values (?, ?, ?)" parameters="ID LASTNAME ADDRESS"/>
> > In the client code we will typically have
> > DataObject customer = root.createDataObject("CUSTOMER");
> > customer.setInt("ID", 720);
> > customer.set("LASTNAME", "foobar");
> > customer.set("ADDRESS", "asdfasdf");
> >
> > das.applyChanges(root);
> >
> > Here client has a chance to understand that he needs to set ID,
> LASTNAME,
> > ADDRESS because the config states - parameters="ID LASTNAME ADDRESS"
> and
> > internally we will map names to idx when doing
> > PreparedStatement.setParameter.
> >
> > For the matter of whether it is required to have parameters="ID LASTNAME
> > ADDRESS" , it is required. We can no say parameters="1 2 3" or "X Y Z"
> > because during SDO to Parameter mapping (in ChangeOperation) we need
> the
> > Name of parameter, so Name and Idx both are required.
> >
> > 2)Another place in RDB DAS (this is where Name is removed in JIRA-658)
> > <Command name="InsertCustomers" SQL="insert into CUSTOMER values
> > (?,?,?) " kind="Insert">
> > <Parameter direction="IN" index="1" columnType="
> commonj.sdo.IntObject
> > "/>
> > <Parameter direction="IN" index="2" columnType="
> commonj.sdo.String"/>
> >
> > <Parameter direction="IN" index="3" columnType="
> commonj.sdo.String"/>
> >
> > </Command>
> >
> > A typical client code will be,
> > Command insert = das.getCommand("InsertCustomers");
> > insert.setParameter(1, "1000");
> > insert.setParameter(2, "MYNAME");
> > insert.setParameter(3, "MYADDR");
> > insert.execute();
> >
> > In this example, nowhere the client has a way to know what 1000, MYNAME
> or
> > MYADDRESS means. If this is a table with many columns and such many
> tables,
> > how the client is going to set values using setParameter() with any
> comfort
> > level, unless otherwise the he has a direct access to database and can
> know
> > the names and order or columns in database table or if the insert syntax
> is
> > used
> > like "insert into CUSTOMER (ID, LASTNAME, ADDRESS) values (?,?,?) "
> >
> > but in tables having large number of rows, it is likely that client will
> > try to have short
> > (insert) statements without column names. And this is what I felt was
> the
> > issue of the user in
> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html, as
> he
> > admitted that even though JDBC does not need Names, he needs it for the
> sake
> > of clarity.
> >
> > So, as such, first thig I am just curious to know is, what were the
> > advantages of JIRA-658?
> >
> > Also, not quite clear about "Also, have you thought about multiple
> queries
> > retrieving the same column,you would have to configure the parameter in
> > multiple places." If there are 10 different Select Commands with 10
> > different Where clauses, we anyway need to set Parameters in 10
> different
> > places.
> >
> > I guess I am completely intepreting something wrong here, please help.
> >
> > Regards,
> > Amita
> >
> > On 7/13/07, Luciano Resende <lu...@gmail.com> wrote:
> > >
> > > The named parameter support was removed from earlier versions of DAS,
> > > here is some previous discussion around the subject [1] See also
> > > tuscany-658. We might need to do further cleanup on the impl, if I
> > > understood correctly.
> > >
> > > As for your second suggestion (parameter column types), could you
> > > expose some use cases scenarios where this would be helpful ? Also,
> > > have you thought about multiple queries retrieving the same column,
> > > you would have to configure the parameter in multiple places.
> > >
> > > [1]
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04672.html
> > > [2] http://issues.apache.org/jira/browse/TUSCANY-658
> > >
> > > On 7/12/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > > Hi,
> > > > A few days ago there was a user question about passing name in
> > > Parameter:-
> > > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html
> > > >
> > > > When checking how Parameters are used in Config, came across the
> > > following
> > > > points.
> > > > There is a difference in Config (SDO) generated Parameter and
> > > > org.apache.tuscany.das.rdb.impl.ParameterImpl.
> > > >
> > > > The one from Config has only ColumnType, Direction and Index whereas
> > > in
> > > > impl, it has
> > > > in addition Name and some other attributes. Not having Name in
> Config
> > > > generated version
> > > > does not cause any problems anywhere as JDBC PreparedStatement
> > > > setParameter() requires
> > > > Index and not Name. But to give a consistent user experience, it can
> > > be good
> > > > to add Name
> > > > (Optional).
> > > >
> > > > Also, when supporting <Create>, <Update>, <Delete> in RDB DAS
> Config,
> > > the
> > > > attribute
> > > > "parameters" is String, which is internally interpreted in Index and
> > > Name.
> > > > This misses
> > > > the ColumnType and Direction.Direction can be safely assumed as IN
> for
> > > these
> > > > statements.
> > > > Also, not supplying ColumnType again causes no issues, as DAS tries
> to
> > > get
> > > > it from database
> > > > metadata or using SDO standards. Still here again, if user can
> specify
> > > > ColumnType (optional),
> > > > it will give a consistent user experiece.
> > > >
> > > > So, question here, for the sake of consistency and uniform user
> > > experience,
> > > > is it a good
> > > > idea to replace [1] with [2]? (Same for <Update> and <Delete>)
> > > >
> > > > [1]<xsd:complexType name="Create">
> > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > <xsd:attribute name="parameters" type="xsd:string"/>
> > > > </xsd:complexType>
> > > >
> > > >
> > > > [2]<xsd:complexType name="Create">
> > > > <xsd:sequence>
> > > > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > > name="Parameter"
> > > > type="config:Parameter"/>
> > > > </xsd:sequence>
> > > > <xsd:attribute name="sql" type="xsd:string"/>
> > > > </xsd:complexType>
> > > >
> > > > Regards,
> > > > Amita
> > > >
> > >
> > >
> > > --
> > > Luciano Resende
> > > Apache Tuscany Committer
> > > http://people.apache.org/~lresende<
> http://people.apache.org/%7Elresende>
> > > http://lresende.blogspot.com/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>
Re: [RDB DAS] Consistent use of Parameters in Config
Posted by Amita Vadhavkar <am...@gmail.com>.
JPQL, Hibernate ,... have support for named parameters.
Why is RDB DAS going in the other way? If there is a reason for switching
off named parameters, please elaborate, else is it OK to go for JIRA-1462?
Regards,
Amita
On 7/13/07, Amita Vadhavkar <am...@gmail.com> wrote:
>
> I went through [1] and [2], it talks about removing name attribute from
> Parameter
> and about generatedKeys. Also saw JIRA-528 on the way. But I could not get
> the exact
> rational behind removing Name from Parameter (It is definitely not
> required
> by JDBC for sure, but can have some aid in usage clarity)....
>
> 1)One place in RDB DAS (here Name is not removed and can not be removed)
> BasicCustomerMappingWithCUD.xml (CRUDWithChangeHistory.testDeleteAndCreate
> ())
> <Config xmlns="http:///org.apache.tuscany.das.rdb/config.xsd">
>
> <Table tableName="CUSTOMER">
> <create sql="insert into customer values (?, ?, ?)" parameters="ID
> LASTNAME ADDRESS"/>
> <update sql="update customer set lastname = ?, address = ? where ID
> = ?" parameters="LASTNAME ADDRESS ID"/>
> <delete sql="delete from customer where ID = ?" parameters="ID"/>
> </Table>
>
> </Config>
>
> This is informative because we have <create sql="insert into customer
> values (?, ?, ?)" parameters="ID LASTNAME ADDRESS"/>
> In the client code we will typically have
> DataObject customer = root.createDataObject("CUSTOMER");
> customer.setInt("ID", 720);
> customer.set("LASTNAME", "foobar");
> customer.set("ADDRESS", "asdfasdf");
>
> das.applyChanges(root);
>
> Here client has a chance to understand that he needs to set ID, LASTNAME,
> ADDRESS because the config states - parameters="ID LASTNAME ADDRESS" and
> internally we will map names to idx when doing
> PreparedStatement.setParameter.
>
> For the matter of whether it is required to have parameters="ID LASTNAME
> ADDRESS" , it is required. We can no say parameters="1 2 3" or "X Y Z"
> because during SDO to Parameter mapping (in ChangeOperation) we need the
> Name of parameter, so Name and Idx both are required.
>
> 2)Another place in RDB DAS (this is where Name is removed in JIRA-658)
> <Command name="InsertCustomers" SQL="insert into CUSTOMER values
> (?,?,?) " kind="Insert">
> <Parameter direction="IN" index="1" columnType="commonj.sdo.IntObject
> "/>
> <Parameter direction="IN" index="2" columnType="commonj.sdo.String"/>
>
> <Parameter direction="IN" index="3" columnType="commonj.sdo.String"/>
>
> </Command>
>
> A typical client code will be,
> Command insert = das.getCommand("InsertCustomers");
> insert.setParameter(1, "1000");
> insert.setParameter(2, "MYNAME");
> insert.setParameter(3, "MYADDR");
> insert.execute();
>
> In this example, nowhere the client has a way to know what 1000, MYNAME or
> MYADDRESS means. If this is a table with many columns and such many tables,
> how the client is going to set values using setParameter() with any comfort
> level, unless otherwise the he has a direct access to database and can know
> the names and order or columns in database table or if the insert syntax is
> used
> like "insert into CUSTOMER (ID, LASTNAME, ADDRESS) values (?,?,?) "
>
> but in tables having large number of rows, it is likely that client will
> try to have short
> (insert) statements without column names. And this is what I felt was the
> issue of the user in
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html, as he
> admitted that even though JDBC does not need Names, he needs it for the sake
> of clarity.
>
> So, as such, first thig I am just curious to know is, what were the
> advantages of JIRA-658?
>
> Also, not quite clear about "Also, have you thought about multiple queries
> retrieving the same column,you would have to configure the parameter in
> multiple places." If there are 10 different Select Commands with 10
> different Where clauses, we anyway need to set Parameters in 10 different
> places.
>
> I guess I am completely intepreting something wrong here, please help.
>
> Regards,
> Amita
>
> On 7/13/07, Luciano Resende <lu...@gmail.com> wrote:
> >
> > The named parameter support was removed from earlier versions of DAS,
> > here is some previous discussion around the subject [1] See also
> > tuscany-658. We might need to do further cleanup on the impl, if I
> > understood correctly.
> >
> > As for your second suggestion (parameter column types), could you
> > expose some use cases scenarios where this would be helpful ? Also,
> > have you thought about multiple queries retrieving the same column,
> > you would have to configure the parameter in multiple places.
> >
> > [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04672.html
> > [2] http://issues.apache.org/jira/browse/TUSCANY-658
> >
> > On 7/12/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > > Hi,
> > > A few days ago there was a user question about passing name in
> > Parameter:-
> > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html
> > >
> > > When checking how Parameters are used in Config, came across the
> > following
> > > points.
> > > There is a difference in Config (SDO) generated Parameter and
> > > org.apache.tuscany.das.rdb.impl.ParameterImpl.
> > >
> > > The one from Config has only ColumnType, Direction and Index whereas
> > in
> > > impl, it has
> > > in addition Name and some other attributes. Not having Name in Config
> > > generated version
> > > does not cause any problems anywhere as JDBC PreparedStatement
> > > setParameter() requires
> > > Index and not Name. But to give a consistent user experience, it can
> > be good
> > > to add Name
> > > (Optional).
> > >
> > > Also, when supporting <Create>, <Update>, <Delete> in RDB DAS Config,
> > the
> > > attribute
> > > "parameters" is String, which is internally interpreted in Index and
> > Name.
> > > This misses
> > > the ColumnType and Direction.Direction can be safely assumed as IN for
> > these
> > > statements.
> > > Also, not supplying ColumnType again causes no issues, as DAS tries to
> > get
> > > it from database
> > > metadata or using SDO standards. Still here again, if user can specify
> > > ColumnType (optional),
> > > it will give a consistent user experiece.
> > >
> > > So, question here, for the sake of consistency and uniform user
> > experience,
> > > is it a good
> > > idea to replace [1] with [2]? (Same for <Update> and <Delete>)
> > >
> > > [1]<xsd:complexType name="Create">
> > > <xsd:attribute name="sql" type="xsd:string"/>
> > > <xsd:attribute name="parameters" type="xsd:string"/>
> > > </xsd:complexType>
> > >
> > >
> > > [2]<xsd:complexType name="Create">
> > > <xsd:sequence>
> > > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > name="Parameter"
> > > type="config:Parameter"/>
> > > </xsd:sequence>
> > > <xsd:attribute name="sql" type="xsd:string"/>
> > > </xsd:complexType>
> > >
> > > Regards,
> > > Amita
> > >
> >
> >
> > --
> > Luciano Resende
> > Apache Tuscany Committer
> > http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
> > http://lresende.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: [RDB DAS] Consistent use of Parameters in Config
Posted by Amita Vadhavkar <am...@gmail.com>.
I went through [1] and [2], it talks about removing name attribute from
Parameter
and about generatedKeys. Also saw JIRA-528 on the way. But I could not get
the exact
rational behind removing Name from Parameter (It is definitely not required
by JDBC for sure, but can have some aid in usage clarity)....
1)One place in RDB DAS (here Name is not removed and can not be removed)
BasicCustomerMappingWithCUD.xml (CRUDWithChangeHistory.testDeleteAndCreate
())
<Config xmlns="http:///org.apache.tuscany.das.rdb/config.xsd">
<Table tableName="CUSTOMER">
<create sql="insert into customer values (?, ?, ?)" parameters="ID
LASTNAME ADDRESS"/>
<update sql="update customer set lastname = ?, address = ? where ID =
?" parameters="LASTNAME ADDRESS ID"/>
<delete sql="delete from customer where ID = ?" parameters="ID"/>
</Table>
</Config>
This is informative because we have <create sql="insert into customer values
(?, ?, ?)" parameters="ID LASTNAME ADDRESS"/>
In the client code we will typically have
DataObject customer = root.createDataObject("CUSTOMER");
customer.setInt("ID", 720);
customer.set("LASTNAME", "foobar");
customer.set("ADDRESS", "asdfasdf");
das.applyChanges(root);
Here client has a chance to understand that he needs to set ID, LASTNAME,
ADDRESS because the config states - parameters="ID LASTNAME ADDRESS" and
internally we will map names to idx when doing
PreparedStatement.setParameter.
For the matter of whether it is required to have parameters="ID LASTNAME
ADDRESS" , it is required. We can no say parameters="1 2 3" or "X Y Z"
because during SDO to Parameter mapping (in ChangeOperation) we need the
Name of parameter, so Name and Idx both are required.
2)Another place in RDB DAS (this is where Name is removed in JIRA-658)
<Command name="InsertCustomers" SQL="insert into CUSTOMER values (?,?,?)
" kind="Insert">
<Parameter direction="IN" index="1" columnType="commonj.sdo.IntObject"/>
<Parameter direction="IN" index="2"
columnType="commonj.sdo.String"/>
<Parameter direction="IN" index="3"
columnType="commonj.sdo.String"/>
</Command>
A typical client code will be,
Command insert = das.getCommand("InsertCustomers");
insert.setParameter(1, "1000");
insert.setParameter(2, "MYNAME");
insert.setParameter(3, "MYADDR");
insert.execute();
In this example, nowhere the client has a way to know what 1000, MYNAME or
MYADDRESS means. If this is a table with many columns and such many tables,
how the client is going to set values using setParameter() with any comfort
level, unless otherwise the he has a direct access to database and can know
the names and order or columns in database table or if the insert syntax is
used
like "insert into CUSTOMER (ID, LASTNAME, ADDRESS) values (?,?,?) "
but in tables having large number of rows, it is likely that client will try
to have short
(insert) statements without column names. And this is what I felt was the
issue of the user in
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html, as he
admitted that even though JDBC does not need Names, he needs it for the sake
of clarity.
So, as such, first thig I am just curious to know is, what were the
advantages of JIRA-658?
Also, not quite clear about "Also, have you thought about multiple queries
retrieving the same column,you would have to configure the parameter in
multiple places." If there are 10 different Select Commands with 10
different Where clauses, we anyway need to set Parameters in 10 different
places.
I guess I am completely intepreting something wrong here, please help.
Regards,
Amita
On 7/13/07, Luciano Resende <lu...@gmail.com> wrote:
>
> The named parameter support was removed from earlier versions of DAS,
> here is some previous discussion around the subject [1] See also
> tuscany-658. We might need to do further cleanup on the impl, if I
> understood correctly.
>
> As for your second suggestion (parameter column types), could you
> expose some use cases scenarios where this would be helpful ? Also,
> have you thought about multiple queries retrieving the same column,
> you would have to configure the parameter in multiple places.
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04672.html
> [2] http://issues.apache.org/jira/browse/TUSCANY-658
>
> On 7/12/07, Amita Vadhavkar <am...@gmail.com> wrote:
> > Hi,
> > A few days ago there was a user question about passing name in
> Parameter:-
> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html
> >
> > When checking how Parameters are used in Config, came across the
> following
> > points.
> > There is a difference in Config (SDO) generated Parameter and
> > org.apache.tuscany.das.rdb.impl.ParameterImpl.
> >
> > The one from Config has only ColumnType, Direction and Index whereas in
> > impl, it has
> > in addition Name and some other attributes. Not having Name in Config
> > generated version
> > does not cause any problems anywhere as JDBC PreparedStatement
> > setParameter() requires
> > Index and not Name. But to give a consistent user experience, it can be
> good
> > to add Name
> > (Optional).
> >
> > Also, when supporting <Create>, <Update>, <Delete> in RDB DAS Config,
> the
> > attribute
> > "parameters" is String, which is internally interpreted in Index and
> Name.
> > This misses
> > the ColumnType and Direction.Direction can be safely assumed as IN for
> these
> > statements.
> > Also, not supplying ColumnType again causes no issues, as DAS tries to
> get
> > it from database
> > metadata or using SDO standards. Still here again, if user can specify
> > ColumnType (optional),
> > it will give a consistent user experiece.
> >
> > So, question here, for the sake of consistency and uniform user
> experience,
> > is it a good
> > idea to replace [1] with [2]? (Same for <Update> and <Delete>)
> >
> > [1]<xsd:complexType name="Create">
> > <xsd:attribute name="sql" type="xsd:string"/>
> > <xsd:attribute name="parameters" type="xsd:string"/>
> > </xsd:complexType>
> >
> >
> > [2]<xsd:complexType name="Create">
> > <xsd:sequence>
> > <xsd:element maxOccurs="unbounded" minOccurs="0"
> name="Parameter"
> > type="config:Parameter"/>
> > </xsd:sequence>
> > <xsd:attribute name="sql" type="xsd:string"/>
> > </xsd:complexType>
> >
> > Regards,
> > Amita
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [RDB DAS] Consistent use of Parameters in Config
Posted by Luciano Resende <lu...@gmail.com>.
The named parameter support was removed from earlier versions of DAS,
here is some previous discussion around the subject [1] See also
tuscany-658. We might need to do further cleanup on the impl, if I
understood correctly.
As for your second suggestion (parameter column types), could you
expose some use cases scenarios where this would be helpful ? Also,
have you thought about multiple queries retrieving the same column,
you would have to configure the parameter in multiple places.
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04672.html
[2] http://issues.apache.org/jira/browse/TUSCANY-658
On 7/12/07, Amita Vadhavkar <am...@gmail.com> wrote:
> Hi,
> A few days ago there was a user question about passing name in Parameter:-
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html
>
> When checking how Parameters are used in Config, came across the following
> points.
> There is a difference in Config (SDO) generated Parameter and
> org.apache.tuscany.das.rdb.impl.ParameterImpl.
>
> The one from Config has only ColumnType, Direction and Index whereas in
> impl, it has
> in addition Name and some other attributes. Not having Name in Config
> generated version
> does not cause any problems anywhere as JDBC PreparedStatement
> setParameter() requires
> Index and not Name. But to give a consistent user experience, it can be good
> to add Name
> (Optional).
>
> Also, when supporting <Create>, <Update>, <Delete> in RDB DAS Config, the
> attribute
> "parameters" is String, which is internally interpreted in Index and Name.
> This misses
> the ColumnType and Direction.Direction can be safely assumed as IN for these
> statements.
> Also, not supplying ColumnType again causes no issues, as DAS tries to get
> it from database
> metadata or using SDO standards. Still here again, if user can specify
> ColumnType (optional),
> it will give a consistent user experiece.
>
> So, question here, for the sake of consistency and uniform user experience,
> is it a good
> idea to replace [1] with [2]? (Same for <Update> and <Delete>)
>
> [1]<xsd:complexType name="Create">
> <xsd:attribute name="sql" type="xsd:string"/>
> <xsd:attribute name="parameters" type="xsd:string"/>
> </xsd:complexType>
>
>
> [2]<xsd:complexType name="Create">
> <xsd:sequence>
> <xsd:element maxOccurs="unbounded" minOccurs="0" name="Parameter"
> type="config:Parameter"/>
> </xsd:sequence>
> <xsd:attribute name="sql" type="xsd:string"/>
> </xsd:complexType>
>
> Regards,
> Amita
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [RDB DAS] Consistent use of Parameters in Config
Posted by Luciano Resende <lu...@gmail.com>.
The named parameter support was removed from earlier versions of DAS,
here is some previous discussion around the subject [1] See also
tuscany-658. We might need to do further cleanup on the impl, if I
understood correctly.
As for your second suggestion (parameter column types), could you
expose some use cases scenarios where this would be helpful ? Also,
have you thought about multiple queries retrieving the same column,
you would have to configure the parameter in multiple places.
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04672.html
[2] http://issues.apache.org/jira/browse/TUSCANY-658
On 7/12/07, Amita Vadhavkar <am...@gmail.com> wrote:
> Hi,
> A few days ago there was a user question about passing name in Parameter:-
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html
>
> When checking how Parameters are used in Config, came across the following
> points.
> There is a difference in Config (SDO) generated Parameter and
> org.apache.tuscany.das.rdb.impl.ParameterImpl.
>
> The one from Config has only ColumnType, Direction and Index whereas in
> impl, it has
> in addition Name and some other attributes. Not having Name in Config
> generated version
> does not cause any problems anywhere as JDBC PreparedStatement
> setParameter() requires
> Index and not Name. But to give a consistent user experience, it can be good
> to add Name
> (Optional).
>
> Also, when supporting <Create>, <Update>, <Delete> in RDB DAS Config, the
> attribute
> "parameters" is String, which is internally interpreted in Index and Name.
> This misses
> the ColumnType and Direction.Direction can be safely assumed as IN for these
> statements.
> Also, not supplying ColumnType again causes no issues, as DAS tries to get
> it from database
> metadata or using SDO standards. Still here again, if user can specify
> ColumnType (optional),
> it will give a consistent user experiece.
>
> So, question here, for the sake of consistency and uniform user experience,
> is it a good
> idea to replace [1] with [2]? (Same for <Update> and <Delete>)
>
> [1]<xsd:complexType name="Create">
> <xsd:attribute name="sql" type="xsd:string"/>
> <xsd:attribute name="parameters" type="xsd:string"/>
> </xsd:complexType>
>
>
> [2]<xsd:complexType name="Create">
> <xsd:sequence>
> <xsd:element maxOccurs="unbounded" minOccurs="0" name="Parameter"
> type="config:Parameter"/>
> </xsd:sequence>
> <xsd:attribute name="sql" type="xsd:string"/>
> </xsd:complexType>
>
> Regards,
> Amita
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org