Thanks Kevin, for correcting the example, I actually meant what you have assumed :)
Also, another question in JDK5 context, the code will be very precise and type checking/assumptions about types can be avoided in many places in DAS using JDK5 generics. Other features from JDK5 can be used too. So, I am just curious to know the different pros and cons about using JDK1.4 vs. using JDK5. Regards, Amita On 8/30/07, Kevin Williams <[EMAIL PROTECTED]> wrote: > > 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] > >