Debugging DBUnit

Today was more debugging of DBUnit bugs that was still plaguing our test cases. At first we thought the problem was that Hibernate was not creating the DB schema before DBUnit could load the database. So we tried opening/creating a session in the constructor of the testcase before dbunit loaded the sample.xml file into the HSQLDB. This, still produced errors about tables not being found. Eventually, after many attempts on changing the configuration of both Hibernate and DBUnit, we realized that DBUnit did not recognize it's own XML file it created from its Maven2 plugin incarnation. This makes utterly no sense and was unfathomable as to why it would create incompatible formats of XML files for backup. This seemed to be the root of the problem, even though the hunch of having to open a Hibernate session in the TestCase's constructor was still correct since DBUnit does not store the table's schema inside it's XML backups. Since the backup from the Maven2 dbunit plugin no longer worked, we had to first re-import the sample dataset into the server using the maven dbunit plugin, write a function (it's in a Main class right now) to export the database programmatically using the dbunit JAR (and its myriad of dependencies). Now that the JUnit tests work, we plan to encapsulate the quirks of the JUnit into its own subclass so we don't have to write boiler plate cold for each test file. Our test cases can use dbunit functions to compare the manipulated DB and the resulting DB as well as all the standard JUnit asserts.

Web Service Updates

Okay, today on the web services front we got the XSD (XML Schema) file written that defines the schema for public art objects in XML. We also finished working on the WSDL (although it will be expanded as we fill in the web service later). We have a NetBeans project up and running with our service and are looking into running some tests to make sure everything is working as it is supposed to. We are using a NetBeans plugin for SoapUI to allow for testing of the service. Namespaces in the XML have been a confusing issue but I think we got everything worked out today.

More on DBunit

We have only been trying to get dbunit to work as for backing up and restoring the database. This was done using the Maven2 plugin. However, when there is a need for having a sample dataset loaded every single time a test runs (e.g. during setUp() for JUnit) it isn't practical. This is because a Maven2 plugin can only be attached to a certain phase of the Maven2 build lifecycle, meaning the sample dataset would only load once at the beginning of all tests. So in order to have the sample dataset load for each test, we added the dbunit 2.3.0 as a dependency in Maven2 and use its original implementation. It has it's own DBTestCase class instead of the JUnit testcase, which is, we believe, just a subclass of the JUnit TestCase class anyway. It can also be used in a regular JUnit TestCase class as well, the initialization of some DBUnit specific variables just have to be done manually. This changes what we have been previously done for tests, which is simply programmatically inserting values through Hibernate, then running tests on the few tests we did. Now, we have 150 rows of sample data from the Public Art application as our test data. There are still some issues, but should be resolved summarily as we understand more about DBUnit.

More work with Web Services

Today we were given access to the university and have been able to spend a couple of hours working there so far.

One thing that we worked on was setting up our web service. We have been researching SOAP and WSDL files (This article has been helpful for understanding WSDL). We have started working on our WSDL file and defining how our objects are going to be represented in XML schema. We've got part of the WSDL written, but it will need to be expanded as we actually start integrating our Framework into the Web Service. We also set up a web project in NetBeans that we are going to develop our Web Service in.

Daily Entry for Tuesday, October 28th (DB & CODE)

Today, we found out how to do the unit testing in another scope, without altering the real data in on the server. First, we realized that in Maven2, the test source folder has it's own resource folder. We copied and changed values of the original hibernate.cfg.xml from MYSQL dialect to the HSQLDB dialect. This way the test can be run offline, without a test server.

As for the dbunit plugin, we can now run database backup and restoration through a maven command since the configuration data has been added to the POM.xml.

• To Backup: type "dbunit:export"
• To Restore: type "dbunit:operation"

The backup file will be taken from the "[project path]\backup\backup.xml" and it also restores from that location. This should be changed later to different files and should have the data automatically appended to the filename. The first database backup is on sourceforge documents. We also found out how to export the database schema in SQL programmatically. The schema is uploaded along with the backup of the database on sourceforge. We also commented some code in MDOManager as well as added the function to find by proximity.

Researching Web Services

One of the things we did today was look into web services that we could use on top of our framework. We looked at using a RESTful web service first, but it after evaluating it, we realized that it is not as good of a solution as SOAP for what we are trying to do. We found an example for setting up a SOAP project in NetBeans and are looking more into how to write a WSDL file for our service. We also are most likely going to send the object data via XML.

After going through that tutorial, I was able to get the Web Service set up, but we still need to make our own bare-bones WSDL file and start integrating it with our framework as that gets more fleshed out.

Daily Entry for Monday, October 27th

Today, we started by adding values to all of our tracker tasks. We also split up and refined the tasks some more. We also met with Prof. Carrera today to talk about our iteration plans. We set up a meeting for tomorrow and also talked about the internet situation. Prof. Carrera said that the University is in the process of giving us access and with any luck we should have it tomorrow. In the meantime, we were given a key so that we can use the VPC at night.

So tonight we are in the VPC. We are working on using DBUnit so that we can export our database to XML and keep a copy (this XML will also be used when running JUnit tests). After, we will import the correct data into both tables and keep a copy with our project. We are also researching how to create a web service so that we can begin doing that in the near future. We are also trying to get access to the digital pictures that go along with the public art data.

Introduction rough draft

Today, one of the things we did was write a draft of the introduction for the report. It will be posted on sourceforge soon, but at the moment our dial-up will not allow us to access, so I posted it on google documents here

EDIT: posted on sourceforge documents now

Trackers and Requirements

We created the basic requirements today.

Here is the Google Doc link, and here is the SF link.

We are currently in the process of turning the objectives in this document into trackers on the SF site. The progress can be monitored here. The trackers will be divided by what portion of the project they pertain to (Data, Base Framework, Location-Specific Framework, Web Service, Application).

In Venice

We are still working on getting reliable internet through the University with Professor Carrera. In the meantime, we will work on the introduction to our report, as well as preparing items for the tracker. More updates to follow.

New version of UML diagram up on sourceforge

Today we worked some on the UML diagram. We're also going to flesh out the plan of work a little more.


Here is the UML diagram:

Also, here is the revised plan of work:

https://sourceforge.wpi.edu/sf/docman/do/viewDocument/projects.veniceb08/docman.root/doc6325/2?_message=1224013582838

Tentative schedule up on sourceforge

Our tentative schedule of work is up on SourceForge. Have a look:

https://sourceforge.wpi.edu/sf/go/doc6325?nav=1

Current UML Daigram and Scenarios

Here is our current version of our Object Model. This is a very rough draft and we still have some questions regarding some of the associations and methods.



















Here is a link to the current scenarios.

Public Art Columns

ONLY Public Art Columns NOT MDO

Here are the following columns that we will transfer from the access MDB files to our DB and object mapping.

• Normalized Year (Anno Normalizzato)
• Medium (Materiale)
• Type (Tipo)
• Subtype (Sottotipo)
• Family (Famiglia)
  
• Conservation Level (Conservazione Rizzi Numere)
  

Work thus far this week

This week, we began brainstorming and writing scenarios on Monday and Tuesday. On Tuesday we started putting together a UML class diagram to help us wrap our heads around the details of what our framework would do in each scenario. We've been thinking about the overall design and all of the classes that we would need for our framework to work in a reasonable fashion. We hope to finish the UML diagram later today and work on getting a couple more scenarios written up.

Scenarios

We need to create scenarios for several calls on the framework. We'll post them here.

Iteration Meeting

We discussed about expounding the "update" use case. How will we append an extra MDO? Will this require changing the framework or extending the framework? There is a possibility that this process needs to be documented for the "application programmer". This lead us to come up with different actors...

• framework developer
• application programmer

Professor Pollice decided our use cases needed to be more detailed, especially on the interaction between our framework and google maps/mapping services/other services during which the use case would be realized.

Added e-mail notification to blog

I added e-mail notification to the blog so now it should be easier to keep updated with our progress.

Some DocumentWorthy Progress

I just committed some code to the SVN repository. I believe it was significant enough for me to post because there are some major changes and additions I made to the code that may not be clear just at glance. Here are my commit bullet points...

• - Added JavaDoc to all existing classes

• - Refactored testing to the appropriate test package instead of using a main method

• - Added GenericDao.java so far for the DAO pattern, more work needs to be done, but it is functional as of now

• - Added log4j properties file and added logging for testing, this also means greater control in hibernate debug messages. By changing the properties files we can turn on logging to a point that every single transaction is shown in the log, it also allows for us to redirect the logging to a file (which will be useful in production)
  

• - Refactored Hibernate Annotation mapping into HibernateUtil.java

• - Added the "new SchemaExport()" line when initializing HibernateUtil so we can programmatically change if the tables are being dropped and recreated. This is in direct response to the original code that would keep dropping and recreating tables. I later found out this was specified in the XML and even though XML and programmatic means may mingle, I decided on deleting the XML config for this particular function and specify this configuration in HibernateUtil.
  

DbUnit for testing and moving datasets

There was the belief that hibernate would make our dataset portable to any underlying database. However, it seems that out-of-the-box, Hibernate does make our framework portable but not the dataset. This meant we would have to either write importers or exporters for our specific schema. Well, it seems that this JUnit extension called DbUnit @ http://dbunit.sourceforge.net/ solves the problem. It is also a maven plugin where it can both export and import large datasets using XML during testing to prevent data corruption. It uses the JDBC driver so it will be DBMS agnostic. Of course this will help us in unit testing as well.

More detailed use cases posted

More detailed use cases for our framework have been posted on SourceForge:
https://sourceforge.wpi.edu/sf/go/doc6265?nav=1

This covers all of the use cases we could think of when going through scenarios where our framework would be used.