Re: [MO-java-dev] com.mockobjects.sql review.

[Jeff M. <je...@mk...>]

One at a time would be my preferred method. If you can chuck us patches
for some of the simpler atomic changes we'll work up to the bigger
moving files around stuff.

What everyone needs to remember is that I've only got a really small
head and I can't cope with more than one or two changes at a time.

On Mon, 2002-09-16 at 17:23, Simon Levitt wrote:
> As part of my role to evaluate/develop the MockObjects SQL functionality 
> I've re-worked some of the classes in order to satisfy the testing 
> requirements we'd like to meet.
> 
> I've also been looking at them in order to implement a 
> MockCallableStatement (Not yet done).
> 
> I'd like to present my current set of changes back to the group for 
> comments and/or inclusion into the codebase.
> 
> They are as follows:
> 
> - ExpectationMap & ReturnObjectList
>     - methods to enable and perform the verify()cation of objects
>       contained therein. Default to original functionality.
>     - ReturnObjectList keeps its list of objects to allow above.
> 
> - CommonMockConnection 
>     - method to allow the automated checking of associated
>       PreparedStatements.
>     - Automatically associates Statements with Connection on return.
> 
> - CommonMockStatement:
>     - INTERFACE CHANGE: setExpectedQueryString now makes given query the
>       only one on the object. addExpectedQueryString allows more to be 
>       added. Did this for constancy more than anything.
>     - setupResultSet/setupAddResultSet used to set/add ResultSets to the 
>       connection.
>     - addResultSet deprecated (in favour to setupAddResultSet().
>     - An update count is treated the same as a normal ResultSet - more 
>       closely follows the java.jdbc specification (eg. a Statement result 
>       is either a ResultSet or an update count).
>       The query counts are queued with the ResultSets for retrieval after
>       execute calls.
>     - Automatically associates ResultSets with the Statement on return. 
>     - method to allow the automated checking of associated ResultSets.
> 
> ResultSets (in general)
>     - CommonMockResult created in jdk/common that defines single a
>       ResultSet interface that supports single & multi row result sets.
>     - Allows the verification/expectation checking of row data retrieval
>       from all rows (not just the first).
>     - Each jdk/<version>/com/mockobjects/sql now defines a single 
>       MockResultSet that allows the definition of JDK specific additional 
>       methods/interfaces that may be required. MockResultSet removed from
>       jdk/common. Now uses a similar model to Connection and Statement.
>     - MockSingleRowResultSet & MockMultiRowResultSet objects/interfaces 
>       retained for backwards compatibility (moved into jdk/common - 
>       extends MockResultSet defined in jdk/<version>)). Both removed
>       from jdk/<version> trees.
>       MockMultiRowResultSet basically just defines a single deprecated
>       method from its original interface (MockResultSet defines the rest).
>     - MockUpdateResultSet added for update count support (extends 
>       MockSingleRowResultSet).
>     - POTENTIAL issue: These changes add a requirement that 
>       jdk/common/com/mockobjects/sql needs a jdk/<version> derived
>       MockResultSet in order to compile. (Doesn't break ant build though).
>     - Can now set/add to the row name mappings and rows returned.
>       MockSingleRowResultSet allows setting/adding of individual elements 
>       within the row.
>     - If name mapping supplied, can use name and/or index to access row 
>       data. (Name mapping currently needs to be supplied before data to 
>       work correctly).
>     - Automatically associates ResultSet with Statement on return.
>     - method to allow the automated checking of Row expectations.
> 
> Given that there is a fair bit of class movement in these changes how 
> should supply these (a cvs diff -u doesn't cope with new/deleted files).
> 
> Perhaps a CVS branch where I could commit these to?
> 
> Other things I'd like to do:
> 
> - Develop a DeferredException class that causes an exception to be
>   thrown after a certain number of events has occured (eg. throws an 
>   SQLException on the third call to next() on a ResultSet)
> - Add mechanism for specifying a particular value on a row shouldn't be
>   retrieved (code may be retrieving different columns depending on data
>   it find in others).
> - Add support for Statements that return Multiple resultSets on one 
>   execution. (Not that high a priority).
> 
> Cheers,
> 
> Simon.,
> -- 
> --------------------------------------------------------------------------
>          Simon Levitt, Senior Development Engineer @ WorldPay plc,
> WorldPay Centre, The Science Park, Milton Rd., Cambridge, CB4 0WE, ENGLAND  
>  Sim...@uk...   Ph:+44(0)1223 715151  F:+44(0)1223 715157
> ------------------------- http://www.worldpay.com/ -----------------------
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
-- 
jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 5547 8331
phone: 44 (0) 20 2226 4545
email: je...@mk...

www.mkodo.com