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
