ThinkGeo.com    |     Documentation    |     Premium Support

EditTools, get ID for Feature after Commit

Hi,


when I commit a transaction I like to get the ID of all the feature created in the underlaying data source.


Example: I have some geometries on EditOverlay. Now save them to the data source (maybe PostGIS table).


Each feature created will get an ID in transaction and in the PostGIS table as well. Both Ids are not the same. How to retrieve the new ID from PostGIS?


Any ideas?


Regards


Hardy



Hi Hardy,



I didn’t get a PostGis database to test, but I have some insights on it.

What I am guessing is we need to add a column in the each feature from the EditOverlay, the column name is the same as the FeatureIdColumn which we specified in PostgreSqlFeatureLayer and then the column value is the new ID you want to store in database. For instance, we define postgis layer:



PostgreSqlFeatureLayer layer = new PostgreSqlFeatureLayer(connection, tableName, “UID”);



when we add the feature, we have the codes:

            Feature newFeature = new Feature();
            newFeature.ColumnValues[“UID”] = “FeatureId”;



            layer.EditTools.BeginTransaction();
            layer.EditTools.Add(newFeature);
            layer.EditTools.CommitTransaction();



Then, after the commit, we should can retrieve the feature with the original ID value from database.

If the issue persist, please feel free to let us know or it’s better you can attach some codes or sample.



Thanks,

Troy

 







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



Hi Hardy,



I just noticed there is a field named “fid” which might be useful in your implement way currently. If the fid is useless, I think we can give is an unique value when inserting a record into table. Then we can retrieve this record by calling GetFeatureByValues method. This is just a simple guessing and if it is not fit for your scenario, please skip it.



As for getting the effected feature ids, I am afraid we won’t extend such APIs. In my opinions, since we are using a “transaction” to handler the inserting/deleting/editing together, it’s hard to split the effected results for each of them. Besides, to get the effected records information like ids , this will need one more query to the database and this will bring a bad performance.



Any more questions, don’t hesitate to let us know.

Thanks,

Troy

Hi Troy,


fid is a pointer/foreign key to a non spatial dataset we are storing in feature's row.


You suggestion is ok but I will use an other attribute in the feature record.


Regards


Hardy



Hi Hardy, 
  
 Okay, if any questions, don’t hesitate to let us know. 
 Thanks, 
 Troy