My Ingres Blog

JUnit test will INITIALIZE (but try nothing) if you have:
1. The TestSetup class
2. The db.properties resource

It will TRY to connect to Ingres (but skip the tests) if you have:
3. The Ingres JDBC drivers downloaded.
4. The JDBC drivers referenced in pom.xml
5. The JDBC drivers referenced by db.properties’ Driver field.

It will connect to Ingres and FAIL the tests if you have:
6. An Ingres instance running
7. db.properties contain relevant and correct connection information
(address and protocol type, username, password)

It will PASS the tests if you have:
8. Ingres instance SUPPORTS Geospatial datatypes.
9. Unit tests logic are correct.
10. Source implementations are correct.

————–

Is it just running “mvn test" that causes the tests to run?

mvn install compiles then runs the tests

——————-

Make sure you read more carefully the error messages from mvn, I had
the same problem building after I added the dependency tag into
pom.xml. But turns out its because I was not careful with the xml
tags.
After some fixing it works. So to confirm here’s the last few lines of
my pom.xml:

</developers>

<dependencies>
<dependency>
<groupId>com.ingres.jdbc</

This part is based on the test classes for PostGIS

PostGISTestSetup needs PostGISDialect which extends BasicSQLDialect

so do we need IngresDialect?

notice it also needs PostGISNGDataStoreFactory

This part is based on the test suite for DB2. According the class usage from test classes, we need to have the following classes (name in bold is the test class name)

DB2TestSetup

IngresUtil

IngresTestUtil

IngresNGDataStoreFactory

JDBCDataStoreTest: research again

JDBCSpatialFiltersTest

IngresDataStore
Other test classes don’t require any other jdbc classes other than those mentioned above

This is just roadmap of further studying

DB2SQLDialect vs. OracleSQLDialect

DB2SQLDialect extends SQLDialect
OracleDialect extends PreparedStatementSQLDialect

DB2FilterToSQL vs. OracleFilterToSQL
1.createFilterCapabilities()
instantitated different capabilities

2.visitBinarySpatialOperator()
DB2:visitBinarySpatialOperator(BinarySpatialOperator filter, Object extraData, String db2Predicate)
Oracle:
visitBinarySpatialOperator(BinarySpatialOperator filter, PropertyName property,
Literal geometry, boolean swapped, Object extraData)

OracleNGDataStoreFactory vs. OracleNGDataStoreFactory

1.createDataStoreInternal(JDBCDataStore dataStore, Map params)
Oracle:
// make the schema uppercase if it’s not already
if(dataStore.getDatabaseSchema() != null)
dataStore.setDatabaseSchema(dataStore.getDatabaseSchema().toUpperCase());

// setup loose bbox
OracleDialect dialect = (OracleDialect) dataStore.getSQLDialect();
Boolean loose = (Boolean) LOOSEBBOX.lookUp(params);
dialect.setLooseBBOXEnabled(loose == null || Boolean.TRUE.equals(loose));

// setup proper fetch size
dataStore.setFetchSize(200);

DB2:

try {
con = dataStore.getDataSource().getConnection();
DatabaseMetaData md = con.getMetaData();
MajorVersion=md.getDatabaseMajorVersion();
MinorVersion=md.getDatabaseMinorVersion();
ProductName=md.getDatabaseProductName();
ProductVersion=md.getDatabaseProductVersion();
} catch (SQLException e) {
throw new IOException(e.getMessage());
}
dataStore.closeSafe(con);

2.getJDBCUrl
Oracle
String host = (String) HOST.lookUp(params);
String db = (String) DATABASE.lookUp(params);
int port = (Integer) PORT.lookUp(params);
if( db.startsWith(“(“) )
return JDBC_PATH + db;
else if( db.startsWith(“/”) )
return JDBC_PATH + “//” + host + “:” + port + db;
else
return JDBC_PATH + host + “:” + port + “:” + db;
DB2:
String host=null;
Integer port = null;
try {
host = (String) HOST.lookUp(params);
port = (Integer) PORT.lookUp(params);
} catch (IOException ex) {
// do nothing
}

String db = (String) DATABASE.lookUp(params);

if (host==null && port== null && db !=null)
return “jdbc:”+getDatabaseID()+”:”+db;

return super.getJDBCUrl(params);

3.  setupParameters(Map parameters)
Oracle:
// NOTE: when adding parameters here remember to add them to OracleNGOCIDataStoreFactory and
// OracleNGJNDIDataStoreFactory

super.setupParameters(parameters);
parameters.put(LOOSEBBOX.key, LOOSEBBOX);
parameters.put(MAX_OPEN_PREPARED_STATEMENTS.key, MAX_OPEN_PREPARED_STATEMENTS);
parameters.put(PORT.key, PORT);
parameters.put(DBTYPE.key, DBTYPE);
DB2:
super.setupParameters(parameters);
parameters.put(DBTYPE.key, DBTYPE);

4.getValidationQuery()
Oracle:
“select sysdate from dual”
DB2:
“select current date from sysibm.sysdummy1″;

OracleNGJNDIDataStoreFactory vs. DB2NGJNDIDataStoreFactory
Constructor
Oracle:
super.setupParameters(parameters);

parameters.put(OracleNGDataStoreFactory.LOOSEBBOX.key, OracleNGDataStoreFactory.LOOSEBBOX);
parameters.put(MAX_OPEN_PREPARED_STATEMENTS.key, MAX_OPEN_PREPARED_STATEMENTS);
DB2:
super(new DB2NGDataStoreFactory());

http://community.ingres.com/wiki/IngresGeoTools
all technical decisions or findings captured in the wiki written as though a perfect stranger may need to pick them up in a year or two. Ensuring this is done very well, demonstrating the high quality of work and professionalism is the foundation to me going after approval to hire one or possibly more of the team. The schedule component should look a little like this please: http://community.ingres.com/wiki/GeoProjectPlan P
—————–

• abstract jdbc tests located here: http://svn.osgeo.org/geotools/branches/2.6.x/modules/library/jdbc/src/test/java/org/geotools/jdbc
• our subclass tests will be located here: http://svn.osgeo.org/geotools/branches/2.6.x/modules/unsupported/jdbc/jdbc-ingres/src/test/java/org/geotools/data/ingres (at least one per class).
• our code should be under “unsupported” for now
• some databases (i.e. postgis) have implementations with options for both plain sql as well as prepared statments. What about ingres?
• openGeo stack workshop: http://workshops.opengeo.org/stack-intro/

——————————

• abstract jdbc tests located here: http://svn.osgeo.org/geotools/branches/2.6.x/modules/library/jdbc/src/test/java/org/geotools/jdbc
• our subclass tests will be located here: http://svn.osgeo.org/geotools/branches/2.6.x/modules/unsupported/jdbc/jdbc-ingres/src/test/java/org/geotools/data/ingres (at least one per class).
• our code should be under “unsupported” for now
• some databases (i.e. postgis) have implementations with options for both plain sql as well as prepared statments. What about ingres?
• openGeo stack workshop: http://workshops.opengeo.org/stack-intro/

—————————-

Prerequisites:

First, make sure you have all the following installed properly.

Maven (with Jetty plug-in, should be shipped together by default, but if not just download seperately)

JDK (you know how to install JDK I hope, except to avoid wierd behaviour, please make sure your full path is contains no space in it, this goes for other software as well hopefully)

Eclipse for Java SE developer

svn(to make sure you’re able to check out source code)

Also make sure you have all the following in your command line environment.

M2_HOME=<directory-to-maven>

JAVA_HOME=<directory-to-JDK>

PATH=%PATH%;%M2_HOME%/bin;%JAVA_HOME%/bin

Steps:

Compile and setup with Maven:

mkdir everythingInsideHere

cd everythingInsideHere

mkdir svn

cd svn

svn co https://svn.codehaus.org/geoserver/trunk geoserver

svn co https://svn.osgeo.org/geotools/trunk geotools

cd geoserver/src

mvn install

mvn eclipse:eclipse

cd ../../geotools

mvn install

mvn eclipse:eclipse

Setup Eclipse:

Run Eclipse into an empty workspace.

Go to Window->Preferences

Under Java->BuildPath->Classpath Variable (or just type classpath variables in the filter search box), make sure an M2_REPO variable is set. If not, click on “New…” and under “Name” type M2_REPO, under “Path” point it to your .m2/repository folder. (For windows, it should be in your username folder)

Under Java->Compiler->Building, make sure .svn is included in the “Filtered resources” field.

Click on OK to close the Preferences window.

Now under the Package Explorer on the left, right click in the empty space and find the Import… menu, click on it.

Select “Existing Projects into Workspace” and click Next

Select root directory to be the exact same directory where you invoked mvn install in your geoserver/src. That should list out a LOT of projects after a long search. Add all of them into eclipse. They should show up in the originally empty Package Explorer, one of which is called “web-app”. Eclipse should automatically build all your project and hopefully there should be no errors.

You need to setup maven jetty to be run as an external tool though. So click on Run->External Tools->External Tools Configuration

Under Program, create a New_configuration if there’s not already an empty one created for you, then the “Main” and “Environment” needs to be setup as follow:

Main

Location: <the actual mvn binary file on your file system, e.g. for Windows its %M2_HOME%/bin/mvn.bat>

Working Directory: Click on “Browse Workspace” and select the web-app project.

Arguments: jetty:run

Environment

Click on “New…” and add the following into the environment variables to set:

Variable: MAVEN_OPTS

Value: -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=8080,server=y,suspend=y

After that you could click apply and ok to close this window (or “RUN” if you want to run immediately)

Invoke Debug instance:

Now you can begin debugging. Run the External Tool configuration you’ve created if you haven’t.

Go to Run->Debug Configurations…

Under “Remote Java Application”, create a new configuration just like you did for External Tool, this time with the following:

Connect

Project: web-app

Connection Type: Standard(Socket Attach)

Connection Properties:

Host: localhost

Port: 8080

CHECK Allow termination of remote VM.

Click Apply, and click Debug

Wait for a while, if all else works out, you should be able to open your browser and go to http://localhost:8080/geoserver/ and get greeted by an instance of Geoserver!

the testing can be broken down into three parts:
1. the JUnit tests
2. the entire application stack (i.e. OpenGeo)

3. programmatically debugging using GeoServer

————————-

The breakpoints to PostgisNGDataStoreFactory also got hit and hence I
also confirmed that its using a
.m2/repository/gt-jdbc-2.7-

classes with similar purpose in DB2 example are in bold. It seems that to implement data access for Ingres, these common classes should be implemented.

For test cases to write, see the info in the google wave post

A natural question: how to configure which database to use?

In org.geotools.data.oracle

1.OracleDateConverterFactory

Implements ConverterFactory

2.OracleDialect

extends PreparedStatementSQLDialect, which in turn implements SQLDialect

3.OracleFilterToSQL

Oracle specific filter encoder, extends PreparedFilterToSQL

OracleNGDataStoreFactory
OracleNGJNDIDataStoreFactory
OracleNGOCIDataStoreFactory
SDO11OracleDialect
SDOOracleDialect
OracleConnectionFactory
OracleDataStore
OracleDataStoreFactory
OracleFeatureLocking
OracleFeatureSource
OracleFeatureStore
OracleFeatureWriter
OracleOCIDataStoreFactory

In org.geotools.data.oracle.attributeio

SDOAttributeIO

In org.geotools.data.oracle.sdo

GeometryConverter

In org.geotools.referencing.factory.epsg

1. FactoryUsingOracleSQL
2. OracleDialectEpsgMediator
3. ThreadedOracleEpsgFactory

I just copy information about code and plan from wave and sum them up a bit

1. UML designed is updated

2. Test

basic plan:Example geospatial data, loaded into Ingres, feeding it to GeoServer (leveraging Geotools with support for Ingres).

run pre existing tests in http://svn.osgeo.org/geotools/branches/2.6.x/modules/library/jdbc/src/test/java/org/geotools/jdbc as well as create our own tests in http://svn.osgeo.org/geotools/branches/2.6.x/modules/unsupported/jdbc/jdbc-ingres/src/test/java/org/geotools/data/ingres (at least one per class).

——

3.

look into OpenGeo http://opengeo.org/community/suite/download/
in particular the GeoServer workshop here: http://workshops.opengeo.org/stack-intro/
diagram in workshop shows GeoServer interacting directly with database. In this diagram geotools would be part of the GeoServer component as GeoServer is built on the geotoolslibary
had trouble installing QGIS, potentially looking into uDig as an alternative for putting data into postgis

Search for types with “DB2″ in their names. I assume that is all database-specific classes we need to implement for Ingres

Data access architecture: http://docs.codehaus.org/display/GEOT/8.4+Data+Access

package org.geotools.data.db2;

1.DB2ConnectionFactory:

deprecated Use {@link DataSource}, {@link DataSourceUtil} and {@link DataSourceFinder} instead

2.DB2DataStore:

DataStore is central in data access

Instances of this class should only be obtained via DB2DataStoreFactory.createDataStore or DataStoreFinder.getDataStore.

3.DB2DataStoreFactory

Implements the DataStoreFactorySpi interface to create an instance of a DB2DataStore.

4.DB2FeatureLocking (extends DB2FeatureStore)

FeatureLocking is used in writing to database.

5.DB2FeatureSource (extends JDBCFeatureSource)

FeatureSource is central in data access.

DB2 Feature Source implementation. Overrides functionality in JDBCFeatureSource to provide more efficient or more appropriate DB2-specific implementation.

6.DB2FeatureStore (extends JDBCFeatureStore)

FeatureStore is used in database wrting.

DB2 FeatureStore implementation. Overrides functionality in JDBCFeatureStore to provide more efficient or more appropriate DB2-specific implementation.

7.DB2FeatureTypeHandler (extends FeatureTypeHandler)

Override methods from FeatureTypeHandler for DB2-specific handling.

(need to research how it is used)

8.DB2FeatureWriter (extends JDBCTextFeatureWriter)

used in writing to DB

9.DB2FIDMapperFactory (extends DefaultFIDMapperFactory)

* Overrides DefaultFIDMapperFactory methods for DB2-specific handling.

(need to research how it is used)

10.DB2GeometryColumn

Hold information about a DB2 geometry column and provide access.

(need to research how it is used)

11.DB2SpatialCatalog

(need to research how it is used)

Manage the DB2 Spatial Extender spatial catalog information in memory to improve performance.

This class is not intended to be used outside the DB2 plug-in package.

Currently, a different catalog is managed for each DB2 database and schema specified in the creation of a DB2DataStore.  Multiple data stores created for the same database and schema can share the same catalog.

All schema, table and column names are case sensitive.

Convenience methods provided for access to various types of catalog information like type names, srid, etc.

* <b>Note: the ‘srid’ value in DB2 is different from the srid value referenced
* in OGC documents.  The OGC srid corresponds more closely to the DB2 ‘csid’
* value. This makes life quite confusing because the DB2 ‘srid’ is needed to
* construct geometries in the database.  GeoTools needs the ‘csid’ which
* generally corresponds to an EPSG coordinate system identifier in order to
* create an OGC coordinate system reference. </b>

* <b> We also assume that there is a single ‘srid’ associated with all the
* geometries in a particular geometry column.  This is not required by DB2.

* Do we need to consider freeing this up at some point as the HashMap of
* catalogs is stored in a class variable?
* </p>

12.DB2SQLBuilder (extends GeoAPISQLBuilder)

A DB2-specific subclass of DefaultSQLBuilder, which supports DB2 Spatial Extender geometry datatypes.

13.DB2NGDataStoreFactory (extends JDBCDataStoreFactory)

DataStoreFactory for DB2 database.

(Notice there are several DataStoreFactory, need to know the difference)

14.DB2NGJNDIDataStoreFactory (extends JDBCJNDIDataStoreFactory)

DataStoreFactory for DB2 database.

15.DB2SQLDialect (extends SQLDialect)

16.DB2SQLDialectBasic (extends BasicSQLDialect)

17.DB2SQLDialectPrepared (extends PreparedStatementSQLDialect)

18.DB2WKBReader

Version of JTS WKB Reader adjusted for DB2

19.DB2WKBWriter

Version of JTS WKB Writer adjusted for DB2

SQLDialect

/**
* The driver used by JDBCDataStore to directly communicate with the database.
* <p>
* This class encapsulates all the database specific operations that JDBCDataStore
* needs to function. It is implemented on a per-database basis.
* </p>
* <p>
*  <h3>Type Mapping</h3>
* One of the jobs of a dialect is to map sql types to java types and vice
* versa. This abstract implementation provides default mappings for “primitive”
* java types. The following mappings are provided. A ‘*’ denotes that the
* mapping is the default java to sql mapping as well.
* <ul>
*   <li>VARCHAR -> String *
*   <li>CHAR -> String
*   <li>LONGVARCHAR -> String
*   <li>BIT -> Boolean
*   <li>BOOLEAN -> Boolean *
*   <li>SMALLINT -> Short *
*   <li>TINYINT -> Short
*   <li>INTEGER -> Integer *
*   <li>BIGINT -> Long *
*   <li>REAL -> Float *
*   <li>DOUBLE -> Double *
*   <li>FLOAT -> Double
*   <li>NUMERIC -> BigDecimal *
*   <li>DECIMAL -> BigDecimal
*   <li>DATE -> java.sql.Date *
*   <li>TIME -> java.sql.Time *
*   <li>TIMESTAMP -> java.sql.Timestmap *
* </ul>
* Subclasses should <b>extend</b> (not override) the following methods to
* configure the mappings:
* <ul>
*   <li>{@link #registerSqlTypeToClassMappings(Map)}
*   <li>{@link #registerSqlTypeNameToClassMappings(Map)}
*   <li>{@link #registerClassToSqlMappings(Map)}
* </ul>
* </p>
* <p>
*
* </p>
* <p>
* This class is intended to be stateless, therefore subclasses should not
* maintain any internal state. If for some reason a subclass must keep some
* state around (not recommended), it must ensure that the state is accessed in
* a thread safe manner.
* </p>

Hierachy:

->BasicSQLDialect->DB2,H2, MySQL,PostGIS,SpatialLite,SQLServer

->DB2SQLDialect

->H2Dialect

->My SQL Dialect

->PreparedStatementSQLDialect->DB2,H2,MySQL, Oracle, PostGIS