Re: [JPP-Devel] Modifying BasicFeature to track modifications

[Paolo Rizzi]

> Hi,
> 
> I have seen two ways to generate unique IDs for new features. First one is 
> based on using integer as ID, and inserting new feature begins with query 
> "select max(ID) from table".  New feature gets value max(ID)+1.  Another, and 
> pretty safe way is to configure database table to take primary key 
> automatically triggered from database sequence. Then it is enough for the 
> client software to send just pure insert request without new ID.  In both 
> cases new query must be done before client can know what was the ID that was 
> finally inserted into database.
Problem is Features not always have a single-numeric field PK, it may be 
an alphanumeric field and/or it may be composed by multiple fields.
The use of auto-increment or sequence fields with values generated by 
the database is common practice, but, if I remeber well, JDBC has not a 
very good support for it (I may be wrong or it may have changed with 
recent JDBC versions).
Also, if you let the RDBMS generate the new PK value, how do you read it 
back??? You can't select the Feature from the DB, because you don't know 
the PK in the first place.
Another problem is with dependant Features. Imagine a ROAD Feature with 
HOUSEs Features along it. The HOUSE Features may use the ROAD's PK to 
"link" themselves to the ROAD itself. If you insert a new ROAD along 
with a few HOUSEs, what value would you use as the ROAD's PK???

> 
> I can imagine that in some cases user knows the proper ID for the new 
> features to be inserted, for example if they are parcels and have some ID in 
> other registers.
Letting the user generate PK values solve, or at least circumvent the 
above problems, but how can the user generate good PKs???
The client may help him by suggesting good values. For example in the 
simple case of a single numeric field PK, the client can do an in-memory 
max()+1 or, if Features were not all read in memory, it may issue a 
"select max()+1" to the DB.
Sure enough there's the possibility of this value to became invalid at 
commit time, but this can happen in any case.

> 
> Simultaneous edits are sometimes prevented with some "get feature with lock" 
> systems.  They tend to be taylor made.
Locking doesn't work very well with spatial data, because working by 
users tends to last for long, so a long-time locking system is required 
by the RDBMS, but it's something that's not always available.
Also, GIS work is often done disconnected, so a better solution may be 
letting the user work as he/she is the only user, and implement into the 
client a system to resolve conflicts at commit time.
Once this conflict-presenting-and-resolving system is in place, one can 
become really sophisticated, and also detect spatial conflicts.
Imagine that user "A" draws a new HOUSE on an empty terrain lot and then 
he/she try to commit it to the DB, but in the meantime user "B" has 
already committed a ROAD on the very same terrain.
This is not a conflict in strict DB parliance, but it's nonetheless a 
real conflict in spatial terms.
It woould be great to have a GIS capable of detecting and presenting to 
the user such conflicts, to be resolved, or at least signalled.

I hope this didn't sounded like a rant, it is not by any mean!!! :-)
Just trying to summarize all problems, even if now it's not the time to 
solve them.

Bye
Paolo Rizzi

> 
> 
> -Alkuperäinen viesti-
> Lähettäjä: Larry Becker [mailto:becker.la...@gmail.com]
> Lähetetty: to 2.4.2009 22:33
> Vastaanottaja: OpenJump develop and use
> Aihe: Re: [JPP-Devel] Modifying BasicFeature to track modifications
>  
> Paolo,
> 
>   You make some good points.  I wasn't really trying to solve all database
> update problems, but here is a try.
> 
> Assumption:  The database PK is stored in an attribute.  In this case
> Features that show modified already have a PK so all is well.  When new
> Features are created, the PK will be null and therefor detectable. The
> problem of assigning unique keys is database dependent.  In the case of
> deleted Features, this must be handled by a Layer Listener that keeps a copy
> of the deleted Features to hold for the next commit.  The problem of
> multiple edits to the same database record is beyond the scope of this
> effort.
> 
> regards,
> Larry
> 
> On Thu, Apr 2, 2009 at 1:44 PM, Paolo Rizzi  wrote:
> 
>> Andreas is right, for this to work for each "modified" Feature it must
>> be known if it was modified, inserted or deleted.
>>
>> Also there's the case of conflict resolving.
>> If user "A" reads a Feature from a DB, modify it and then write it back
>> to the same DB, there's the possibility that in the meantime user "B"
>> had changed, or deleted, the same Feature.
>>
>> To be able to manage and resolve conflicts, the system should have
>> available multiple version of the same Feature:
>>- the original version user "A" read from the DB
>>- the version modified by user "A"
>>- the modified version by user "B", that is now in the 

Re: [JPP-Devel] Modifying BasicFeature to track modifications

[Larry Becker]

Hi Paolo,

  Thanks for continuing this very interesting discussion.  You make a good
point about not knowing the ID when auto-increment is used to generate the
new key.  The solution to this may be (after db inserts) to reissue the
spatial query that loaded the Features from the database in the first
place.  This may be possible by calling FeatureDataset invalidateEnvelope(),
although perhaps this only works for DataStores.

I haven't had any problem using auto-increment in my own JDBC database code
with the H2 database.

For cases where the PK is hand generated alphanumeric, you could just assume
the user has filled out the attribute, issue the database insert, and pass
on referential integrity errors to the user (i.e. NULL PK not allowed).

Your idea about detecting spatial conflicts is visionary.  I see no reason
this couldn't be done, probably with database triggers.

regards,
Larry

2009/4/3 Paolo Rizzi 

> > Hi,
> >
> > I have seen two ways to generate unique IDs for new features. First one
> is based on using integer as ID, and inserting new feature begins with query
> "select max(ID) from table".  New feature gets value max(ID)+1.  Another,
> and pretty safe way is to configure database table to take primary key
> automatically triggered from database sequence. Then it is enough for the
> client software to send just pure insert request without new ID.  In both
> cases new query must be done before client can know what was the ID that was
> finally inserted into database.
> Problem is Features not always have a single-numeric field PK, it may be
> an alphanumeric field and/or it may be composed by multiple fields.
> The use of auto-increment or sequence fields with values generated by
> the database is common practice, but, if I remeber well, JDBC has not a
> very good support for it (I may be wrong or it may have changed with
> recent JDBC versions).
> Also, if you let the RDBMS generate the new PK value, how do you read it
> back??? You can't select the Feature from the DB, because you don't know
> the PK in the first place.
> Another problem is with dependant Features. Imagine a ROAD Feature with
> HOUSEs Features along it. The HOUSE Features may use the ROAD's PK to
> "link" themselves to the ROAD itself. If you insert a new ROAD along
> with a few HOUSEs, what value would you use as the ROAD's PK???
>
> >
> > I can imagine that in some cases user knows the proper ID for the new
> features to be inserted, for example if they are parcels and have some ID in
> other registers.
> Letting the user generate PK values solve, or at least circumvent the
> above problems, but how can the user generate good PKs???
> The client may help him by suggesting good values. For example in the
> simple case of a single numeric field PK, the client can do an in-memory
> max()+1 or, if Features were not all read in memory, it may issue a
> "select max()+1" to the DB.
> Sure enough there's the possibility of this value to became invalid at
> commit time, but this can happen in any case.
>
> >
> > Simultaneous edits are sometimes prevented with some "get feature with
> lock" systems.  They tend to be taylor made.
> Locking doesn't work very well with spatial data, because working by
> users tends to last for long, so a long-time locking system is required
> by the RDBMS, but it's something that's not always available.
> Also, GIS work is often done disconnected, so a better solution may be
> letting the user work as he/she is the only user, and implement into the
> client a system to resolve conflicts at commit time.
> Once this conflict-presenting-and-resolving system is in place, one can
> become really sophisticated, and also detect spatial conflicts.
> Imagine that user "A" draws a new HOUSE on an empty terrain lot and then
> he/she try to commit it to the DB, but in the meantime user "B" has
> already committed a ROAD on the very same terrain.
> This is not a conflict in strict DB parliance, but it's nonetheless a
> real conflict in spatial terms.
> It woould be great to have a GIS capable of detecting and presenting to
> the user such conflicts, to be resolved, or at least signalled.
>
> I hope this didn't sounded like a rant, it is not by any mean!!! :-)
> Just trying to summarize all problems, even if now it's not the time to
> solve them.
>
> Bye
> Paolo Rizzi
>
> >
> >
> > -Alkuperäinen viesti-
> > Lähettäjä: Larry Becker [mailto:becker.la...@gmail.com]
> > Lähetetty: to 2.4.2009 22:33
> > Vastaanottaja: OpenJump develop and use
> > Aihe: Re: [JPP-Devel] Modifying BasicFeature to track modifications
> >
> > Paolo,
> >
> >   You make some good points.  I wasn't really trying to solve all
> database
> > update problems, but here is a try.
> >
> > Assumption:  The database PK is stored in an attribute.  In this case
> > Features that show modified already have a PK so all is well.  When new
> > Features are created, the PK will be null and therefor detectable. The
> > problem of assigning unique keys 

Re: [JPP-Devel] Good News for Google Summer of Code

[Sunburned Surveyor]

Stefan,

I can surely assist you with turning in the reports this summer. We'll
work it out.

SS

On Thu, Apr 2, 2009 at 1:58 PM, Stefan Steiniger  wrote:
> So.. I requested now to be a mentor for OSGeo using the google SofC
> pages. I guess somebody at OSGeo will handle that?
>
> ... lets see what happens...
>
> As I once previously pointed out, I am probably of in August so we need
> to check later then how we submit the reports while I am traveling
>
> stefan
>
> Sunburned Surveyor wrote:
>> Stefan,
>>
>> That is great news! I don't know how I missed your e-mail on the topic. 
>> Sorry.
>>
>> If I end up with two students being interested I will hit up Andreas.
>> Otherwise I'll see if I can steer one of them to Geotools.
>>
>> SS
>>
>>
>> On Wed, Apr 1, 2009 at 11:04 AM, Stefan Steiniger  wrote:
>>> Hei,
>>>
>>> Landon, I don't know if you read my other emails - I also have a student
>>> at my university that wrote me last friday. He will apply and I will ask
>>> him to focus on the projection stuff for his application.
>>>
>>> Stefan
>>>
>>> Sunburned Surveyor wrote:
 Andreas wrote: "Did any of the students seem to have interest in this?"

 I can surely ask them. I'll get back to everyone on this.

 SS

 On Wed, Apr 1, 2009 at 9:10 AM, Andreas Schmitz  wrote:
> Sunburned Surveyor wrote:
>
> Hi,
>
>> I'd like to know if Stefan would be willing to take his own student
>> this year. If Stefan can't make room for this, I know Andreas from the
>> deegree Project has already volunteered.
> while I can mentor students with almost any topic, I'd like to point out 
> that a
> reprojection plugin for OpenJUMP based on deegree has a couple of 
> interesting
> benefits as a project for a SOC student (IMHO):
>
>  * it's something that'd bring an exciting functionality to OpenJUMP
>  * it's not that hard to implement
>  * it's not required to dig too deep into both OpenJUMP or deegree code
>  * it's been thought of and asked for for quite some time now
>  * using deegree as a library enables us to integrate the rest of deeJUMP 
> and
>   the WFSPlugin into the OpenJUMP core without any effort besides copying 
> the
>   code
>  * I'm a member of both development communities ;-)
>
> Did any of the students seem to have interest in this?
>
> Best regards, Andreas
> --
> l a t / l o n  GmbH
> Aennchenstrasse 19           53177 Bonn, Germany
> phone ++49 +228 18496-12     fax ++49 +228 1849629
> http://www.lat-lon.de        http://www.deegree.org
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAknTkfAACgkQ737OVr+Ru7pN9gCgouJds0nkL4tKj6SBM5JfC4Zs
> zkYAoM+ciNpwp/9VqXMf7CQnGIhkJill
> =QH0q
> -END PGP SIGNATURE-
>
> --
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
 --
 ___
 Jump-pilot-devel mailing list
 Jump-pilot-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


>>> --
>>> ___
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>
>>
>> --
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>
>
> --
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Modifying BasicFeature to track modifications

[Paolo Rizzi]

> Hi Paolo,
> 
>   Thanks for continuing this very interesting discussion.  You make a 
> good point about not knowing the ID when auto-increment is used to 
> generate the new key.  The solution to this may be (after db inserts) to 
> reissue the spatial query that loaded the Features from the database in 
> the first place.  This may be possible by calling FeatureDataset 
> invalidateEnvelope(), although perhaps this only works for DataStores.
...but if you inserted more than one new Faeture, how do you know which 
is which??? You should have "another" key of some form, to match them.
Anyway the same problems arise in any non-GIS RDBMS client, so a little 
of investigation on existing code should give good answers!!!

> 
> I haven't had any problem using auto-increment in my own JDBC database 
> code with the H2 database.
Yes, I wasn't sure on this point, so it probably _is_ handled in JDBC.

> 
> For cases where the PK is hand generated alphanumeric, you could just 
> assume the user has filled out the attribute, issue the database insert, 
> and pass on referential integrity errors to the user (i.e. NULL PK not 
> allowed).
Sure, in fact a user-friendly error recovering system is very important, 
even for cases when the PK is generated by the DB, because errors may 
still occur, so the the user should be able to manage them and save its 
data in a way or the other, maybe to a temporary storage (binary files 
of some form). If he/she worked hard for hours, it has the right to save 
his/her work somewhere, before going on investigating what went wrong 
with the DB.
Anyway the mechanism can be refined over time, what is needed for a 
start is a good dirty-cache to store modified/inserted/deleted feature. 
This may also come handy if one wanted to implement some form of undo!!!

> 
> Your idea about detecting spatial conflicts is visionary.  I see no 
> reason this couldn't be done, probably with database triggers.
Thank you, I like the term "visionary"!!! :-)

> 
> regards,
> Larry

Bye
Paolo Rizzi

> 
> 2009/4/3 Paolo Rizzi mailto:g...@oicom.com>>
> 
>  > Hi,
>  >
>  > I have seen two ways to generate unique IDs for new features.
> First one is based on using integer as ID, and inserting new feature
> begins with query "select max(ID) from table".  New feature gets
> value max(ID)+1.  Another, and pretty safe way is to configure
> database table to take primary key automatically triggered from
> database sequence. Then it is enough for the client software to send
> just pure insert request without new ID.  In both cases new query
> must be done before client can know what was the ID that was finally
> inserted into database.
> Problem is Features not always have a single-numeric field PK, it may be
> an alphanumeric field and/or it may be composed by multiple fields.
> The use of auto-increment or sequence fields with values generated by
> the database is common practice, but, if I remeber well, JDBC has not a
> very good support for it (I may be wrong or it may have changed with
> recent JDBC versions).
> Also, if you let the RDBMS generate the new PK value, how do you read it
> back??? You can't select the Feature from the DB, because you don't know
> the PK in the first place.
> Another problem is with dependant Features. Imagine a ROAD Feature with
> HOUSEs Features along it. The HOUSE Features may use the ROAD's PK to
> "link" themselves to the ROAD itself. If you insert a new ROAD along
> with a few HOUSEs, what value would you use as the ROAD's PK???
> 
>  >
>  > I can imagine that in some cases user knows the proper ID for the
> new features to be inserted, for example if they are parcels and
> have some ID in other registers.
> Letting the user generate PK values solve, or at least circumvent the
> above problems, but how can the user generate good PKs???
> The client may help him by suggesting good values. For example in the
> simple case of a single numeric field PK, the client can do an in-memory
> max()+1 or, if Features were not all read in memory, it may issue a
> "select max()+1" to the DB.
> Sure enough there's the possibility of this value to became invalid at
> commit time, but this can happen in any case.
> 
>  >
>  > Simultaneous edits are sometimes prevented with some "get feature
> with lock" systems.  They tend to be taylor made.
> Locking doesn't work very well with spatial data, because working by
> users tends to last for long, so a long-time locking system is required
> by the RDBMS, but it's something that's not always available.
> Also, GIS work is often done disconnected, so a better solution may be
> letting the user work as he/she is the only user, and implement into the
> client a system to resolve conflicts at commit time.
> Once this conflict-presenting-and-resolving system is in place, o

Re: [JPP-Devel] Modifying BasicFeature to track modifications

[Larry Becker]

> ...but if you inserted more than one new Faeture, how do you know which
> is which??? You should have "another" key of some form, to match them.


Ah, but why do you care which is which?  It is only necessary to reload the
Features.

Larry

>
> >
> > I haven't had any problem using auto-increment in my own JDBC database
> > code with the H2 database.
> Yes, I wasn't sure on this point, so it probably _is_ handled in JDBC.
>
> >
> > For cases where the PK is hand generated alphanumeric, you could just
> > assume the user has filled out the attribute, issue the database insert,
> > and pass on referential integrity errors to the user (i.e. NULL PK not
> > allowed).
> Sure, in fact a user-friendly error recovering system is very important,
> even for cases when the PK is generated by the DB, because errors may
> still occur, so the the user should be able to manage them and save its
> data in a way or the other, maybe to a temporary storage (binary files
> of some form). If he/she worked hard for hours, it has the right to save
> his/her work somewhere, before going on investigating what went wrong
> with the DB.
> Anyway the mechanism can be refined over time, what is needed for a
> start is a good dirty-cache to store modified/inserted/deleted feature.
> This may also come handy if one wanted to implement some form of undo!!!
>
> >
> > Your idea about detecting spatial conflicts is visionary.  I see no
> > reason this couldn't be done, probably with database triggers.
> Thank you, I like the term "visionary"!!! :-)
>
> >
> > regards,
> > Larry
>
> Bye
> Paolo Rizzi
>
> >
> > 2009/4/3 Paolo Rizzi mailto:g...@oicom.com>>
> >
> >  > Hi,
> >  >
> >  > I have seen two ways to generate unique IDs for new features.
> > First one is based on using integer as ID, and inserting new feature
> > begins with query "select max(ID) from table".  New feature gets
> > value max(ID)+1.  Another, and pretty safe way is to configure
> > database table to take primary key automatically triggered from
> > database sequence. Then it is enough for the client software to send
> > just pure insert request without new ID.  In both cases new query
> > must be done before client can know what was the ID that was finally
> > inserted into database.
> > Problem is Features not always have a single-numeric field PK, it may
> be
> > an alphanumeric field and/or it may be composed by multiple fields.
> > The use of auto-increment or sequence fields with values generated by
> > the database is common practice, but, if I remeber well, JDBC has not
> a
> > very good support for it (I may be wrong or it may have changed with
> > recent JDBC versions).
> > Also, if you let the RDBMS generate the new PK value, how do you read
> it
> > back??? You can't select the Feature from the DB, because you don't
> know
> > the PK in the first place.
> > Another problem is with dependant Features. Imagine a ROAD Feature
> with
> > HOUSEs Features along it. The HOUSE Features may use the ROAD's PK to
> > "link" themselves to the ROAD itself. If you insert a new ROAD along
> > with a few HOUSEs, what value would you use as the ROAD's PK???
> >
> >  >
> >  > I can imagine that in some cases user knows the proper ID for the
> > new features to be inserted, for example if they are parcels and
> > have some ID in other registers.
> > Letting the user generate PK values solve, or at least circumvent the
> > above problems, but how can the user generate good PKs???
> > The client may help him by suggesting good values. For example in the
> > simple case of a single numeric field PK, the client can do an
> in-memory
> > max()+1 or, if Features were not all read in memory, it may issue a
> > "select max()+1" to the DB.
> > Sure enough there's the possibility of this value to became invalid
> at
> > commit time, but this can happen in any case.
> >
> >  >
> >  > Simultaneous edits are sometimes prevented with some "get feature
> > with lock" systems.  They tend to be taylor made.
> > Locking doesn't work very well with spatial data, because working by
> > users tends to last for long, so a long-time locking system is
> required
> > by the RDBMS, but it's something that's not always available.
> > Also, GIS work is often done disconnected, so a better solution may
> be
> > letting the user work as he/she is the only user, and implement into
> the
> > client a system to resolve conflicts at commit time.
> > Once this conflict-presenting-and-resolving system is in place, one
> can
> > become really sophisticated, and also detect spatial conflicts.
> > Imagine that user "A" draws a new HOUSE on an empty terrain lot and
> then
> > he/she try to commit it to the DB, but in the meantime user "B" has
> > already committed a ROAD on the very same terrain.
> > This is not a co

Re: [JPP-Devel] Modifying BasicFeature to track modifications

[Rahkonen Jukka]

Hi,

We play with WFS-T at work, where the mechanism of what really happens finally 
is hidden behind datastore drivers of WFS server like Geoserver or others.  
Anyhow, the problem is still the same than with direct connections to database. 
 For example this document is handling rather similar situation and may be 
refreshing reading.

http://geoserver.org/display/GEOS/Versioning+WFS+-+Sample+calls

-Jukka Rahkonen-

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Modifying BasicFeature to track modifications

[Paolo Rizzi]

> 
> ...but if you inserted more than one new Faeture, how do you know which
> is which??? You should have "another" key of some form, to match them.
> 
>  
> Ah, but why do you care which is which?  It is only necessary to reload 
> the Features.
Yes, true, you are right!!!
It should work, throw away what is inside the dirty-bbox and reload it.
But you better not actually throw away anything before the 
commit-and-reload went OK, or you risk to loose the user work!!!

> 
> Larry

Bye
Paolo


> 
> 
>  >
>  > I haven't had any problem using auto-increment in my own JDBC
> database
>  > code with the H2 database.
> Yes, I wasn't sure on this point, so it probably _is_ handled in JDBC.
> 
>  >
>  > For cases where the PK is hand generated alphanumeric, you could just
>  > assume the user has filled out the attribute, issue the database
> insert,
>  > and pass on referential integrity errors to the user (i.e. NULL
> PK not
>  > allowed).
> Sure, in fact a user-friendly error recovering system is very important,
> even for cases when the PK is generated by the DB, because errors may
> still occur, so the the user should be able to manage them and save its
> data in a way or the other, maybe to a temporary storage (binary files
> of some form). If he/she worked hard for hours, it has the right to save
> his/her work somewhere, before going on investigating what went wrong
> with the DB.
> Anyway the mechanism can be refined over time, what is needed for a
> start is a good dirty-cache to store modified/inserted/deleted feature.
> This may also come handy if one wanted to implement some form of undo!!!
> 
>  >
>  > Your idea about detecting spatial conflicts is visionary.  I see no
>  > reason this couldn't be done, probably with database triggers.
> Thank you, I like the term "visionary"!!! :-)
> 
>  >
>  > regards,
>  > Larry
> 
> Bye
> Paolo Rizzi
> 
>  >
>  > 2009/4/3 Paolo Rizzi mailto:g...@oicom.com>
> >>
>  >
>  >  > Hi,
>  >  >
>  >  > I have seen two ways to generate unique IDs for new features.
>  > First one is based on using integer as ID, and inserting new
> feature
>  > begins with query "select max(ID) from table".  New feature gets
>  > value max(ID)+1.  Another, and pretty safe way is to configure
>  > database table to take primary key automatically triggered from
>  > database sequence. Then it is enough for the client software
> to send
>  > just pure insert request without new ID.  In both cases new query
>  > must be done before client can know what was the ID that was
> finally
>  > inserted into database.
>  > Problem is Features not always have a single-numeric field
> PK, it may be
>  > an alphanumeric field and/or it may be composed by multiple
> fields.
>  > The use of auto-increment or sequence fields with values
> generated by
>  > the database is common practice, but, if I remeber well, JDBC
> has not a
>  > very good support for it (I may be wrong or it may have
> changed with
>  > recent JDBC versions).
>  > Also, if you let the RDBMS generate the new PK value, how do
> you read it
>  > back??? You can't select the Feature from the DB, because you
> don't know
>  > the PK in the first place.
>  > Another problem is with dependant Features. Imagine a ROAD
> Feature with
>  > HOUSEs Features along it. The HOUSE Features may use the
> ROAD's PK to
>  > "link" themselves to the ROAD itself. If you insert a new
> ROAD along
>  > with a few HOUSEs, what value would you use as the ROAD's PK???
>  >
>  >  >
>  >  > I can imagine that in some cases user knows the proper ID
> for the
>  > new features to be inserted, for example if they are parcels and
>  > have some ID in other registers.
>  > Letting the user generate PK values solve, or at least
> circumvent the
>  > above problems, but how can the user generate good PKs???
>  > The client may help him by suggesting good values. For
> example in the
>  > simple case of a single numeric field PK, the client can do
> an in-memory
>  > max()+1 or, if Features were not all read in memory, it may
> issue a
>  > "select max()+1" to the DB.
>  > Sure enough there's the possibility of this value to became
> invalid at
>  > commit time, but this can happen in any case.
>  >
>  >  >
>  >  > Simultaneous edits are sometimes prevented with some "get
> feature
>  > with lock" systems.  They tend to be taylor made.
>  > Locking doesn't work very well with spati

Re: [JPP-Devel] Modifying BasicFeature to track modifications

[Paolo Rizzi]

> Hi,
> 
> We play with WFS-T at work, where the mechanism of what really happens 
> finally is hidden behind datastore drivers of WFS server like Geoserver or 
> others.  Anyhow, the problem is still the same than with direct connections 
> to database.  For example this document is handling rather similar situation 
> and may be refreshing reading.
> 
> http://geoserver.org/display/GEOS/Versioning+WFS+-+Sample+calls
If I remember well WFS-T has an advantage in this respect, because when 
you insert new features, you send them without the PKs and the server 
_answers_ back with the very same content you sent, but with the PK 
values it generated.
So in the very same transaction you send your new Feature and obtain 
their generated PKs. With JDBC alone this can't be done, I believe...
Anyway a WFS-T inspiration is surely useful!!!

> 
> -Jukka Rahkonen-

Bye
Paolo

> 
> --
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel