On Thu, Apr 2, 2009 at 4:15 PM, Rahkonen Jukka <jukka.rahko...@mmmtike.fi>wrote:
> 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. > Agreed. For most databases this is the preferred solution. This would be implemented in the specific database driver and not in the core. Larry > > 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. > > Simultaneous edits are sometimes prevented with some "get feature with > lock" systems. They tend to be taylor made. > > > -----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 <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 > > > 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 > > > > > > -- > http://amusingprogrammer.blogspot.com/ > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Jump-pilot-devel mailing list > 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
