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
