gvSIG bugs #378
postgis cursor already exists
Status: | Fixed | % Done: | 0% | |
---|---|---|---|---|
Priority: | Normal | |||
Assignee: | ||||
Category: | - | |||
Target version: | - | |||
Severity: | Add-on name: | Unknown | ||
gvSIG version: | 1.12.0 | Add-on version: | ||
gvSIG build: | 1204 | Add-on build: | ||
Operative System: | Add-on resolve version: | |||
Keywords: | Add-on resolve build: | |||
Has patch: | No |
Description
From time to time this error is reported in the list. See attached log as example. This happens for various reasons:
- The length of the name of a postgresql cursor is by default limited to 63 characters. The name of the cursor in gvSIG is built based on the name of the table in the database using some parameters as the current time (in milliseconds) of the system as suffix. So, if the name of the layer is big, the cursor name is truncated and it can collide.
The proposed solution is use a random number for the name of the cursor, and check on the catch if it collide, in this case a new random number will be generated.
- The cursor (at least those called wkb_cursor_prov) are never close. This can be checked using this code after the declare statement on the constructor of source:trunk/extensions/extJDBC/src/com/iver/cit/gvsig/fmap/drivers/jdbc/postgis/PostGisFeatureIterator.java
this.rs = st.executeQuery("select * from pg_cursor()");
while (rs.next()) {
System.out.println(rs.getString("name"));
}
Each time a new iterator object is created we can see that the cursors are not close.
This can be fixed changing the code of the closeIterator method.
History
#1
Updated by Francisco Puga over 12 years ago
- File 0001-gvsig-desktop-378.patch
added
Attached patch implements the suggestions
#3
Updated by Álvaro Anguix over 10 years ago
- Project changed from Application: gvSIG desktop to | gvSIG desktop 1
- Target version deleted (
1.12.0-rc1)