> 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 <g...@oicom.com <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 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 > <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 <g...@oicom.com > <mailto:g...@oicom.com>> 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 DB > >> > >> And a mean should exist for the system to present the conflict > to the > >> user and let him decide what to do. > >> > >> Also the Feature must have a PK (Primary Key) inside the DB, or is > >> otherwise impossible to update it. > >> And this leads to another problem, unique PK generation. If a user > >> creates a new Feature, this has to be inserted into the DB. To this > >> effect it needs a new unique PK, that's not already in use in > the DB. If > >> the system is multiuser it may happen that before user "A" > inserts its > >> new Feature into the DB, user "B" inserts its own Feature with > the same > >> PK. Even asking the DB to generate a new PK may not be a good > solution, > >> because each RDBMS has it's own methid for that, and also they > usually > >> do not permit to "reserve" a PK over a period of time. > >> So the best solution is letting user "A" generates a new PK "by > hand" > >> and resolve an eventual conflict at insert time. > >> > >> Even if the system is not multi-user garanteed, the > >> Modified/Inserted/Deleted reasoning is still valid. > >> > >> Bye > >> Paolo Rizzi > >> > >> > >>> Rahkonen Jukka wrote: > >>> > >>> Hi, > >>> > >>>> I wonder how it has been done in a new WFS plugin that can do > >> transactions. > >>>> The transaction icon gets highlighted only if something has been > >> modified, so > >>>> I think there must be some chance tracking system. And I don't > believe > >> really > >>>> that anybody makes a WFS-T client that sends the whole layer > back if > >> only one > >>>> feature is modified. Deegree folks, how is it? > >>> well, loading data from a WFS results in a layer that is an > instance of > >>> WFSLayer. There, all modifications (add/remove/update) are kept > track of, > >> and > >>> they're then mapped to WFS-T insert/update/delete when the user > clicks > >> that > >>> button. A layer listener is used so the layer is notified every > time the > >> user > >>> changes something in a feature or adds/removes one. I think the > features > >> are > >>> stored in seperate lists depending on what has been done with it. > >>> > >>> I'm thinking that you'd need the same information for database > plugins > >> (you > >>> cannot UPDATE a row which needs to be inserted etc.). You can > have a look > >> in the > >>> WFSPlugin/src/de/latlon/deejump/wfs/jump/ classes, in > particular WFSLayer > >> and > >>> the WFSLayerListener. > >>> > >>> Best regards, Andreas > >>> > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> > >> > > ------------------------------------------------------------------------------ > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> Jump-pilot-devel mailing list > >>> Jump-pilot-devel@lists.sourceforge.net > <mailto: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 > <mailto: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 > <mailto:Jump-pilot-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > -- > http://amusingprogrammer.blogspot.com/ > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
