I agree, it is the right time to remove this backward compatibility, as in future , it can add to more confusion. I am chaning the patch for this. ( i.e. removing List and any related methods). Please give any other review comments.
Regards, Amita On 9/3/07, Adriano Crestani <[EMAIL PROTECTED]> wrote: > > Hi everyone, > > I wonder if it is really necessary to keep the back compatibility keeping > the List attribute, once the Tuscany DAS Java is still in beta phase of > develpment. What do you think? > > Regards, > Adriano Crestani > > On 8/30/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > > > > 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/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 <[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/tuscany-dev@ws.apache.org/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/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: > [EMAIL PROTECTED] > > > > > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > >