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