Jody Garnett ha scritto:
> Andrea Aime wrote:
>> Forgot this one... man, your feedback was quite big :-p
> Heh - and this was the only idea I thought was actually good.
>>> GetDiff - GetTransaction Request option
>>> It would be *nice* if the result was *not* a GetFeatures extensions
>>> but instead the exact Transaction request documented required to make
>>> the change; no messing around or inventing new xml schema is requried
>>> here.
Ok, thought about this as well.
Here we have three problems that need to be solved:
a) allow clients some way to display what changed between
revision m and n;
b) allow rollback even if the rollback request is big
c) Chris wanted anyways a way to extract a diff in a patch like
format that allows someone to inspect the change before accepting
it.
Case a) makes me think that the easiest way is to have a GetDiff that
just returns the feature ids of the features that changed between
revision m and n. Then the client can use GetFeature to retrieve
a snapshot of those at m and another snapshot at n (using a fid filter
to tell which feature it wants).
This gives clients whatever they do need to handle a single feature
type, but not to handle multi table changes... the client must be
allowed to ask for specific feature types, or to leave the list open
and receive a list of all fids changed in all feature types.
A request could look like:
<wfs:GetDiff baseVersion="10" targetVersion="35" outputFormat="fids">
<typeNames>
<typeName>roads</typeName>
<typeName>buildings</typeName>
</typeNames
</wfs:GetDiff>
And the answer be something like:
<wfs:ModifiedFids>
<wfs:modifiedFeatures typeName="roads">
<wfs:FeatureId>roads.13</wfs:FeatureId>
<wfs:FeatureId>roads.17</wfs:FeatureId>
</wfs:modifiedFeatures>
<wfs:modifiedFeatures typeName="buildings">
<wfs:FeatureId>building.143</wfs:FeatureId>
</wfs:modifiedFeatures>
</wfs>
Does it sounds like something that makes sense and that the wfs
datastore can support?
Case b) must be supported by a server side only call, something like:
<wfs:Transaction>
<wfs:Native vendorId="Geoserver" safeToIgnore="false">
<wfs:Rollback backToFeatureVersion="15"/>
</wfs:Native>
</wfs:Transaction>
but could be also expressed as a merge as:
<wfs:Transaction>
<wfs:Native vendorId="Geoserver" safeToIgnore="false">
<wfs:Merge fromVersion="LAST" toVersion="15"/>
</wfs:Native>
</wfs:Transaction>
The latter allow us to keep more or less the same vocabulary
when branches are introduced (but version ids may become
branchName:revision).
Case c), I'm not sure about it. It's not needed when you work
totally server side, but it may be an interesting text way to
check what changed, since solution a) is displayable but leaves
the question about what attributes did change to user inspection
or program computation.
This patch format could be indeed a Transaction request.
Cheers
Andrea
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
