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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
