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] > > > > >
