Re: [Geotools-gt2-users] Complex features and nillable

[Falko B. <fa...@po...>]

Thanks Jody, for your reply.

I would raise a bug but currently I'm still trying to figure the ideas behind 
the API. To get things going I make a proposal about API changes. The idea is 
not to actually change things but to have something to discuss about.

----
So, basic idea of my proposal is to have an explicite and clear 
create-modify-update API.

Currently the *FeatureStore* looks like this:

     public interface FeatureStore extends FeatureSource {
         ... addFeatures(FeatureCollection<T, F> collection) ...
         ... modifyFeatures(AttributeDescriptor[], Object[], Filter) ...
     }

These are different concepts to create(add) and to modify features. addFeature() 
forces the store to take an ordinary Feature and translate it into whatever the 
backend needs to create all of its properties. In contrast to modifyFeature() 
which works on property level and so leaves this responsibility to the client 
programm.

Consider the following:

     public interface FeatureStore extends FeatureSource {
         /**
          * Creates a new feature in this store.
          *
          * @param id Feature id, or null.
          * @param initializer Functor that allows to init non-nillable values.
          */
         Feature createFeature(id, initializer) throws ...

         /**
          * Modifies the given Features.
          *
          * @throws IOException If feature does not exist.
          */
         void updateFeatures(FeatureCollection collection) throws ...
     }

Foremost this delegates the problem of identifying complex/collection properties 
to the store (which is a good idea IMO). Besides it is symmetric between create 
and update. And it is easier(?) to use for the client.

Likewise *Feature* (ComplexAttribute):

     public interface ComplexAttribute extends Attribute {
         /**
          * Creates a Property for the given name.
          *
          * @param initializer Functor that allows to init non-nillable values.
          * @throws IllegalArgumentException If 'maxoccurs' exceeded.
          * @throws IllegalArgumentException If the name does not exists in the
          *     FeatureType.
          */
         createProperty(Name name, Initializer initializer);

         /**
          *
          * @return The collection of properties which match the specified name,
          *     or an empty collection if no such properties match.
          * @throws IllegalArgumentException If the name does not exists in the
          *     FeatureType.
          */
         getProperties(Name);

         /**
          *
          * @return The value of this property, or null!!!
          *     or an empty collection if no such properties match.
          * @throws IllegalArgumentException If the name does not exists in the
          *     FeatureType.
          */
         getProperty(Name);
     }

Now there is a clear factory for properties. This allows to let getProperty() 
return null if its value is null (not-initialized).

Ideas:

- Semantic of methods is clear for both primitive and complex values. All the 
questions about semantic and how to work with complex features are solved with 
this API.

- Creating a Feature in the store is very similar to creating a ComplexAttribute 
member inside the Feature. Easier to work with.

- Having the Store being the factory of Features and ComplexAttributes makes it 
much easier to use store dependent Feature implementations. Very important IMO.

- Droping addFeature() in favour of create/modify gives the programmer a better 
idea of the identity of a feature. addFeature() sounds like one can transfer a 
feature from store A into store B - which is not true as ID changes in almost 
all cases.

Jody and all, it would be really great if you could check this, comment and/or 
complain mistakes and/or any misunderstanding of the API.

Thanks!

-Falko

Am 12.09.2014 09:07, schrieb Jody Garnett:
>
>     maybe and hopefully someone can help me with the following questions regarding
>     complex features and properties.
>
>     Question: What is the semantic of: feature.getProperty("foo") == null ?
>
>     1.: the property is not initialized
>     2.: the property is not initialized *or* it does not exist in the type at all
>
>
> If the property did not exist ... it would not be there. The fact that you see a
> property (with a null value) probably indicates something like
> <foo/> is present in the XML. You could consider that significant for your
> application? I am not sure ...
>
> Keep in mind that not a lot of people do this stuff yet (most of use use simple
> features) - and thus you may find our library inconsistent with the GML
> specification (if so raise a bug) or inconsistent with itself (if so raise a bug!).

-- 
Falko Bräutigam
http://polymap.org/polymap3