Hmm. You make good sense. I actually brought that default in when testing against the wfs2 code, but it looks like I didn't look hard enough. As things are implemented, the ResourceIdImpl requires either a Version or a date range. This makes sense to me, as that's mostly what ResourceId adds to FeatureId.
In your example, though, the versioning info is handled by Rid, which is as specific as a Version object. This also isn't settable in other FeatureId implementations, which makes me think that the requirement for ResourceIdImpl should be changed to requiring Version, date range OR featureVersion, and the default only applied when no featureVersion is supplied. This would add a constructor for ResourceIdImpl(String fid). Alternately, we rid ourselves of the default and document the fact that something must be explicitly set. -- Mark On 5 November 2011 13:43, Jody Garnett <[email protected]> wrote: > I thought hard on this one as well; let me read the spec again. > > Right I remember: This case is represent that as a specific FeatureId ( fid + > rid ) to identify a specific record. > > Please not if you are updating geogit mark has been making good progress so > you may want verify you are not duplicating work. He was asking about the > relationship with query.getVersion() for example; hopefully you find those > java docs clear. > > > -- > Jody Garnett > > On 04/11/2011, at 7:25 AM, Gabriel Roldan <[email protected]> wrote: > >> Hello Jody, >> >> in updating my geoserver wfs2 versioning branch to use ResourceId from >> GeoTools trunk I found what looks like an inconsistency in >> ResourceIdImpl: >> >> The following constructor should left the version be null: >> >> public ResourceIdImpl(String fid, String featureVersion) { >> this(fid, featureVersion, new Version(Version.Action.LAST)); >> } >> like in just: >> public ResourceIdImpl(String fid, String featureVersion) { >> super(fid, featureVersion, null ); >> } >> >> Rationale being that when both fid and version is specified, you're >> asking for that specific version of the feature, which is not >> necessarily the LAST one. On the same line, if the specified version >> is not the last one, defaulting to Version.LAST doesn't make sense, as >> there are no other possible states for that specific version. So in >> that case version should be null. At least that's how jdeolive and I >> interpreted the spec and wrote the versioning tests for. >> >> Does that make sense? >> >> Cheers, >> Gabriel >> >> -- >> Gabriel Roldan >> OpenGeo - http://opengeo.org >> Expert service straight from the developers. > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
