David Adler wrote:
>I've checked in the changes to the 22x branch. It would be very helpful if
>someone could check if the PostGIS DataStore still works before I move
>these changes into trunk.
>
>
Hi David,
I've been experimenting with uDig and PostGIS and found an error in
PostGISAutoIncr
I've checked in the changes to the 22x branch. It would be very helpful if
someone could check if the PostGIS DataStore still works before I move
these changes into trunk.
-
Using Tomcat but need to do more? Need to supp
David Adler wrote:
> OK - I will start working on this (It was actually done last year but I
> never checked it in).
>
> Should the changes go in 2.2.x and/or trunk?
>
Both, you may want to make them in trunk first, and then just apply the
fix to 2.2.x with merge when it is ready.
> Is there a
OK - I will start working on this (It was actually done last year but I
never checked it in).
Should the changes go in 2.2.x and/or trunk?
Is there an easy way to move changes in 2.2.x to trunk?
David
At 10:25 AM 7/11/2006, Michael Brasser wrote:
>Up until about a month ago the FIDs generated
Up until about a month ago the FIDs generated by
AutoIncrementFIDMapper were always null. So I would be a bit
surprised if making it abstract broke anything that wasn't already
broken...
In regards to the example, the problem occurs because the database
column actually is autoincrementing
The FIDMapper classes have also caused me considerable aggravation.
I had to subclass AutoIncrementFIDMapper for DB2 in part because each table
name needs to be
qualified by the schema name.
Does anyone use AutoIncrementFIDMapper as it currently exists? If it
changes to abstract, what will it
I can't say I'm super impressed with the current state of the
FIDMapper classes. I'm not an expert but your suggestions make sense
to me.
Jesse
On 10-Jul-06, at 7:43 AM, Michael Brasser wrote:
> Hi David,
>
> Just wanted to mention that there was some discussion on the list
> about a month
Hi David,
Just wanted to mention that there was some discussion on the list
about a month ago about refactoring AutoIncrementFIDMapper. It
currently uses "order by" to return a value, but this is problematic
(I've included a problem case from the earlier discussion below). Not
sure if it w
I would like to implement this and would like to check if anyone has any
objections. The interface should not change except for MaxIncFIDMapper
which I believe incorrectly returns hardcoded Types.VARCHAR for the column
type when it should return the type of the actual fid column. (Since it
as
