Re: [stellation-res] Architectural question/request for opinions

[Annie t Ying <aying@xxxxxxxxxx>]

I have posted a follow-up on this issue:
        http://stellation.eclipse.org/twiki/bin/view/Stellation/MockingDatabaseAccess

Please post any comments on the wiki.
 Thanks!

Annie

Mark C Chu-Carroll/Watson/IBM@IBMUS Sent by: stellation-res-admin@xxxxxxxxxxx 04/01/2004 10:14 AM Please respond to stellation-res

To:        stellation-res@xxxxxxxxxxxxxxx         cc:                 Subject:        [stellation-res] Architectural question/request for opinions

As I've mentioned before, I'm working on the new WVCM backend for Stellation.
 In order to try to avoid some of the grief we've had with changes
to the current system breaking things in subtle ways, and also just because
I think it's the right approach, I'm being *much* more aggressive about
implementing detailed fine-grained unit tests for all of the backend components.

This has led me to one interesting, but somewhat odd problem. There are
two kinds of things that really happen it the backend: making JDBC calls
to store or retrieve data to/from the database; and in-memory data structure
manipulation in order to translate the data from the Stellation SCM abstractions
to and from the raw database data. 

I'd like to be able to test these two aspects separately. The approach
that I'm looking at is based on mock objects - creating a pure memory based
standin for the database access, and using that to test the database. 

The catch is that the way Stellation currently accesses databases is not
particularly friendly to this kind of approach. Stellation generates SQL
strings, and sends them through JDBC, and gets back JDBC result sets. To
write the a really effective mock object for that would be extremely difficult.

I've got an idea for how to handle it, but frankly, I'm having trouble
deciding if it's a good approach, or a dumb one. So I'd like to hear what
you folks think. 

I've put a copy of this up on the wiki at http://stellation.eclipse.org/twiki/bin/view/Stellation/MockingDatabaseAccess;
if you can easily access the wiki, I'd prefer it if you posted comments
there; but if accessing the wiki is a problem, go ahead and post to the
mailing list, and I'll copy them to the wiki. 

So here's the questionable approach. 

We create a new interface in the backend called IStorage. IStorage has
one method for each SQL statement that Stellation uses. Instead of calling
JDBC directly, we call the IStorage method for the particular SQL statement
we want to execute. IStorage methods will take parameters for values that
need to be inserted into SQL calls, and will return query results  translated
from ResultSet's into Lists of object arrays. 

By doing this, we make it really easy to implement a mock for the database
interface; and we also add a bit of extra abstraction that could make it
easier to map Stellation to an object database, or to a non-SQL database.
On the other hand, it seems to me to be sort of ugly and heavy-handed.

So what do you all think? 

        -Mark 





Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM Research
***      http://stellation.eclipse.org
*** Work: mcc@xxxxxxxxxxxxxx/Home: markcc@xxxxxxx