[MO-java-dev] Re: Mock Objects -

[<has...@jp...>]

Jeff

In the Sybase/etc JDBC implementations of this code, the number of times
you call getColumnType etc, is not significant.
I can understand the callls to rs.next() etc being significant, but why
must the call-count to the above be important?
(For this matter the call-count to getColumnName should not be significant
either).

Also, at the moment we have to setup our result set with our expected data
and column names,
then we have to set up our meta data seperately.

    String[] columnNames = TRADE_DATA.getColumnNames();
    singleRowResultSet.addExpectedNamedValues( columnNames,
TRADE_DATA.getColumnValues());

    // setup result set meta data
    resultSetMetaData.setupColumns(columnNames, TRADE_DATA.getColumnTypes
());
    singleRowResultSet.setupMetaData(mockDbAccess.resultSetMetaData);

Would it not be better if these were setup together?
i.e create some sort  of factory which we supply the column names, types
and a set of values and
it creates and returns an appropriate result set. We could then have the
option to change the data in
the result set but the column types and names would be fixed...

p.s Im new to mock objects, so If im missing something obvious, please
accept my apologies!

Haseeb




|---------+---------------------------->
|         |           je...@mk...   |
|         |                            |
|         |           01/21/2003 10:04 |
|         |           AM               |
|         |                            |
|---------+---------------------------->
  >----------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                      |
  |       To:       moc...@li...                                                           |
  |       cc:       has...@jp...                                                                           |
  |       Subject:  Re: Mock Objects -                                                                                   |
  >----------------------------------------------------------------------------------------------------------------------|




The point of this is so you can know how many times a piece of content
is requested.

As far as I'm concerned the difference between

getColumnType(0);

and

getColumnType(0);
getColumnType(0);
getColumnType(0);
getColumnType(0);

is significant.

This is why the ReturnObjectList was used. This means that the exact
number of objects to be returned need to be inserted into the
ReturnObjectList in the order in which they will be requested. However
it maybe more appropriate to use the ReturnObjectBag as this allows the
key value to be taken into consideration. The previous example would
still be significant but the difference between

getColumnType(0);
getColumnType(1);

and

getColumnType(1);
getColumnType(0);

would not be significant. You would still need to load in the correct
number of objects for each key value though. e.g.

setupGetColumnType(0, "value");
getColumnType(0);
getColumnType(0);

would fail

setupGetColumnType(0, "value");
setupGetColumnType(0, "value");
getColumnType(0);
getColumnType(0);

would be successful.

If this sounds okay I can make the change.

On Mon, 2003-01-20 at 23:22, Steve Freeman wrote:
> Sounds like it shouldn't. Jeff, do you want to take this one?
>
> Steve
>
> has...@jp... wrote:
> > Hi
> >
> > I encountered a problem with the MockResultSetMetaData code in 0.7.
> > I viewed the archive and saw a similar problem reported by Vincent
Massoul
> > but I coundlt find out if it was fixed or not:
> >
> >       http://sourceforge.net/mailarchive/message.php?msg_id=2702964
> >
> > Heres the problem...
> >
> > The implementation of the method
> >
> >       getColumnType(i); in the      CommonMockResultSetMetaData class
> >
> > does not match that provided by the 3rdy party driver providers e.g
Sybase
> > - jconnect52.
> >
> > It removes the column type from the underlying vector, so multiple
calls to
> > getColumnType(i),
> > in effect run down the vector (ReturnObjectList).
> > (The code that im writing tests for calls this method more than once
for
> > the same column, hence the problem!).
> >
> > This shouldnt happen, should it?
> >
> > Haseeb Asghar
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > public abstract class CommonMockResultSetMetaData extends MockObject
> > implements ResultSetMetaData {
> >     /**
> >      * Returns the column SQL type.
> >      * DOES NOT SUPPORT THE aColumnIndex PARAMETER.
> >      * You must call getColumnType in order, first to last.
> >      * Column SQL types may be added with setupAddColumnType.
> >      * @see ResultSetMetaData#getColumnType(int)
> >      */
> >     public int getColumnType(int aColumnIndex) throws SQLException {
> >         myColumnTypeIndexes.addActual(aColumnIndex);
> >         return ((Integer) myTypes.nextReturnObject()).intValue();
> >     }
> >
> >
> >
> > public class ReturnObjectList implements Verifiable {
> >     /**
> >      * Returns the next object from the list. Each object it returned
in
> > the
> >      * order in which they where added.
> >      */
> >     public Object nextReturnObject(){
> >         AssertMo.assertTrue(myName + " has run out of objects.",
> >             myObjects.size() > 0);
> >         return myObjects.remove(0);
> >     }
> >
> >
> > This communication is for informational purposes only.  It is not
intended as
> > an offer or solicitation for the purchase or sale of any financial
instrument
> > or as an official confirmation of any transaction. All market prices,
data
> > and other information are not warranted as to completeness or accuracy
and
> > are subject to change without notice. Any comments or statements made
herein
> > do not necessarily reflect those of J.P. Morgan Chase & Co., its
> > subsidiaries and affiliates.
> >

--
Jeff Martin <je...@mk...>






This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.