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

Reply via email to