tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amita Vadhavkar" <amita.vadhav...@gmail.com>
Subject Re: [RDB DAS] Consistent use of Parameters in Config
Date Thu, 02 Aug 2007 08:03:48 GMT
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 <amita.vadhavkar@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 <luckbr1975@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 <amita.vadhavkar@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
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message