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