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