I was more meaning that I updated that page with your change in mind. Please review.
Sphinx is not going to be used until we have a plan and a talk with frank or Justin about deployment. Until then the wiki us our docs. Jody On 23/05/2010, at 6:22 PM, Andrea Aime <[email protected]> wrote: > Jody Garnett ha scritto: >> Wow that is a lot of work. > > A lot of work? ... not really, the non bug fix patches I've been > committing recently were easily 5-10 times bigger. > Or you mean a lot of work on the user part? > >> So you are needing to set the hint on a >> feature by feature basis - suspect we have completely given up on >> Transaction for hint purposes? > > I actually did not remember there was such an idea. > Attaching the hint globally to a transaction is wrong anyways, the > transaction can operate on multiple feature types and you might > want to adopt the useExisting policy only on one of them. > Secondly, in order to support WFS 1.1 style transaction the > hint must be placed on a feature per feature basis. > Here is a XSD snippet for the Insert element (actually, its type): > > <xsd:complexType name="InsertElementType"> > <xsd:sequence> > <xsd:element ref="gml:_Feature" maxOccurs="unbounded"/> > </xsd:sequence> > <xsd:attribute name="idgen" > type="wfs:IdentifierGenerationOptionType" > use="optional" default="GenerateNew"> > </xsd:attribute> > > <xsd:simpleType name="IdentifierGenerationOptionType"> > <xsd:restriction base="xsd:string"> > <xsd:enumeration value="UseExisting"> > </xsd:enumeration> > <xsd:enumeration value="ReplaceDuplicate"> > </xsd:enumeration> > <xsd:enumeration value="GenerateNew"> > </xsd:enumeration> > </xsd:restriction> > </xsd:simpleType> > > As you can see the attribute is placed at the insert element, > which might contain features of multiple types, but at the > same time you can have multiple insert elements, each one > with a different idgen policy, in the same transaction. > Given we have no such grouping > in the GT2 transactions the only way to make a proper translation > without adding extra API is to have a per feature hint. > (the ReplaceDuplicate policy can be implemented by issuing > a delete before the insert so I'm not trying to make an > hint for it, it's not needed) > >> You have not made an api change so >> committing to 2.6.x seems reasonable. Proposals work best when you >> don't have an implementation ready and would like to discuss >> alternatives; I think you did that already in your email discussion. > > The discussion did not really bring much to the table > into the how to do it, so I prototyped it out. Turned out it was > fairly easy, but I'm ready to throw it away, as I said, it > was not that much work actually. > I did not do the patch to force it down your throat, but to have > something real to discuss against given the previous discussion > involved fears of a massive changes and went off the tangent in > other ways: I wanted to show what I was > talking about is no storm, but actually a quite small change. > >> I do ask that we document this somewhere; let me take your existing >> code example and work with it: - >> http://docs.codehaus.org/display/GEOTDOC/07+FeatureStore > > Err... documenting on the wiki? I guess Sphinx is still not used > enough for that purpose... oh well, ok, no problem. > > Cheers > Andrea > > > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
