[Geoserver-users] (no subject)

I’m trying to build an application to synchronize open source server via web feature service.
    The application should mirror the features from the source server to the target server.
    The features are saved in a PostgreSQL Database.
    On the synchronisation the application sends a getFeatures request to the source server, the response will be parsed, and the attributes of the feature are written in an Insert request, this
    request will be send to the target server. As a result of this, I get identical features on the target server and the source server.
    The problem I have is, that the Key value (gid) changes during this operation.
    It seems that geoserver generates a new gid value in place of taking the
    value of the insert request (the highest gid value is added by one). So first:is it a bug or a feature? and second:
    if it's a feature, how can i configure geoserver that it takes MY
    gid-value of the request and not an arbitrary guid?
    I would like to know if it is possible to take over the Key value of the insert Request.
    Example:
    Tag of the insert Request: <cite:states fid="states.246"> old maximum Key value of the source server = 246
    New Key value after insert request at the target server = 247
    Second question is there a maximum number of objects to update?
    When I’m trying to update a huge number of objects I get an error response?
    I will be grateful for your information
    Yours Hendrik
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Hendrik Stuke ha scritto:

I’m trying to build an application to synchronize open source server
via web feature service. The application should mirror the features
from the source server to the target server. The features are saved
in a PostgreSQL Database. On the synchronisation the application
sends a getFeatures request to the source server, the response will
be parsed, and the attributes of the feature are written in an Insert
request, this request will be send to the target server. As a result
of this, I get identical features on the target server and the source
server.

Interesting app.

The problem I have is, that the Key value (gid) changes
during this operation. It seems that geoserver generates a new gid
value in place of taking the value of the insert request (the highest
gid value is added by one). So first:is it a bug or a feature? and second: if it's a feature, how can i configure geoserver that it
takes MY gid-value of the request and not an arbitrary guid?

Heh... you're onto a hard issue. FID are ignored on a couple of levels
unfortunately, the spec does not help, and our feature model neither.

First level is request parsing. FIDs are not parsed, so in-memory features that we do build do not have any reference about the FID you
did provide.

Second level is fid mappers.
Fid mappers are the classes that do map primary keys to Fetures ids and
back. The only problem is, the back part is ignored by most of the FID
mappers, that insist on generating a new feature id.

At spec level, WFS provides a way to report generated
fids for newly inserted features, but it's not clear whether generating
fids is mandatory or not. Since fid attribute in Feature is not mandatory, I think it may not be a bad idea to use the provided one
if available, and generate new ids if none are provided.
And this raises another issue, that is, our in memory feature won't
tell you if a FID has been provided, if none is provided, they'll generate a new one usig a UID approach...
Hmmm... harder and harder to implement it seems.

So, long story short, we need to put in place quite a bit of changes
to make your approach work.
Chris, opinions on this one?

I'm wondering, could you ignore fids and create another column
to be used as your "business" alternate key, and use that one
in your synch requests?

Oh, about the number of features, you have to make sure all features
inserts/updates do fit into memory, so the more memory you allocate,
the bigger is the number of features you can handle. I would suggest
to send requests that aren't bigger.

Cheers
Andrea