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
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-GT2-Users mailing list
GeoTools-GT2-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
