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 <[EMAIL PROTECTED]> 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 <[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/[email protected]/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/[email protected]/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/[email protected]/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]
> > > >
> > > >
> > >
> >
>
