Martin Desruisseaux ha scritto:
The search in the cache is performed in a synchronized block as well. It
is not something like looking for a key in a hash map. It is something
more elaborated involving a comparaison of hints, looking for factories
dependencies and check recursively the
Versioned postgis datastore OOMs on big datasets when performing diff related
operations
Key: GEOT-2029
URL: http://jira.codehaus.org/browse/GEOT-2029
Project:
During the last days I had same mail traffic with David Adler and concerning
the db2 plugin we agreed on the following
1) We want to migrate the old plugin into the new design
I will do the migration, David will assist to get things working
2) We want the plugin to be ready for fat
When I get off the road and back to my desk I'll have a look at the prepared
statement architecture of H2 and decide how that affects the SQL-view
perspective. We are also thinking about blowing apart the complex-datastore
GroupingFeatureIterator to allow it to map multiple source back end
Christian Müller ha scritto:
During the last days I had same mail traffic with David Adler and concerning
the db2 plugin we agreed on the following
1) We want to migrate the old plugin into the new design
I will do the migration, David will assist to get things working
2) We want the
Hi,
I am developing a software that displays a shapefile in a conteiner that in my
database postgis. some maps are shown in container, but others are not . And
the following error appears : java.io.IOException: CRS of this map context is
null. Unable to get bounds.
Someone could help me ?
Jody:
I think we should start some discussions about transaction handling.
Do you know this article
http://static.springframework.org/spring/docs/2.5.5/reference/transaction.ht
ml
Btw, GeoServer uses Spring, GeoServer should do the transaction handling,
not geotools (you know my opinion)
I have been wanting to branch out an old version of trunk used by a
customer so I can make a fix...
svn cp -r30107 http://svn.geotools.org/trunk
http://svn.geotools.org/branches/2.5-fix
That does not work because our repository structure has changed ...
which is fine.
I can check what was
So I really thing the revison history is messed up; going through the
milestones the nearest I have found is:
C:\java\geotools\trunksvn info http://svn.geotools.org/tags/2.5-M2
Path: 2.5-M2
URL: http://svn.geotools.org/tags/2.5-M2
Repository Root: http://svn.geotools.org
Repository UUID:
I was able to recover by sneaking up on the problem ...
1. Branched 2.5-M2 to 2.5-fix
2. Check to see that it was not using any geoapi SNAPSHOT - it was using
2.2-M0 (whew!)
3. Performed a reverse merge to rollback to needed revision:
svn merge -rHEAD:30107
4. I am unsure if I can change the
10 matches
Mail list logo
