Hi Troy,
ok to define a column and to store a temporary ID could work, but using the FeatureIdColumn I think will fail because PostGIS will set the value as the column is defined "serial". Look at the creat statement:
CREATE TABLE gm_fhm_grab_geo
(
gid serial NOT NULL,
fc_ integer DEFAULT 0,
uri text,
rotation double precision DEFAULT 0,
txtrotation double precision DEFAULT 0,
fid integer DEFAULT 0,
editor integer DEFAULT 0,
constructor integer DEFAULT 0,
created date DEFAULT ('now'::text)::date,
lastupdate date DEFAULT ('now'::text)::date,
mandant integer DEFAULT 0,
parentinfo text,
parentformel integer DEFAULT 0,
parent text,
text01 text,
text02 text,
text03 text,
the_geom geometry,
fc character varying(255),
CONSTRAINT gm_fhm_grab_geo_pk PRIMARY KEY (gid),
CONSTRAINT enforce_dims_the_geom CHECK (st_ndims(the_geom) = 2),
CONSTRAINT enforce_srid_the_geom CHECK (st_srid(the_geom) = 31467)
)
I have done a different way. I'm querying the Layer with the shape from the new feature. When retrieving one or more feature stored on the source layer I will use the first item.
As an alternative I think your suggestion is a good way to define a "tempID" column and store the Id from the created feature. After transaction I can query the layer with the "tempID" to retrieve the exact ID from the underlaying layer. This workaround needs a second column in every data table in PostGIS to identify the created feature.
A much more better way (I think) could be to get all (new) FeatureIds from MapSuite like "TransactionResult.EffectedFeatures". MapSuite should know the effected items and get them back. This would extend the current API with a new property.
What do you think about?
Regards
Hardy