> ...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 <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 > -- http://amusingprogrammer.blogspot.com/
------------------------------------------------------------------------------
_______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
