Hi Andrea,
I think there may be a minor issue with the patch. Is there a patch to
look at? I am not sure of exactly the change you are proposing but i
think i ran up against this same issue. If you look at line 1269 on
JDBC1DataStore there is a comment explaining the problem. Basically it
boils down to how some of the feature readers and how they copy
features. Basically some of them just create a null array of attributes
and then set the objects one by one. However if the feature type says
that an attribute cannot be null that code will fail. So the workaround
was to setting minoccurs to > 0 if the attribute was indeed nillable.
So I think the fix will be cool, but like you say I think we will have
to fix code in other places too in both geotools and geoserver.
-Justin
Andrea Aime wrote:
> Chris Holmes ha scritto:
>> I'm pretty sure we're bound by the WFS standard on this. From the spec:
>>
>> 'The response to a GetFeature request must be valid according to the
>> structure described by the XML Schema description of the feature type.
>> Thus the WFS must report all the mandatory properties of each feature,
>> as well any properties requested through the <wfs:PropertyName>
>> element. In the event that a WFS encounters a query that does not
>> select all mandatory properties of a feature, the WFS will internally
>> augment the property name list to include all mandatory property
>> names. A WFS client must thus be prepared to deal with a situation
>> where it receives more property values than it requests through
>> <wfs:PropertyName> elements.'
>>
>> Can you change your data so the geometry isn't required?
>
> Ouff, spent more than two hours on this, but found what changed.
> The difference is made by a little change Justin committed one month
> ago, revision 6125, changelog "formatting", that did not contain only
> formatting, on DataTransferObjectFactory.create(schemaBase, attributeType).
>
> Yet, the real problem is not in Justin change, which really seems
> the right thing to do, but in the overall way attribute type minOccurs
> is handled, which is really a mess.
>
> Let me summarize what is going on.
> (Warning, long horror story ahead, don't let children come near the
> screen).
> The tale begins in the feature type creation. All data stores do use
> DefaultAttributeTypeFactory to build attribute types. On 2.3.x, that
> class always generates attributes with 1:1 min max occurrences.
> On trunk, someone exposed a method that allows for creating attribute
> types with a custom min/max occurrences, but it's used only
> by JDBC data stores for non geometric attributes
> (JDBC1DataStore.buildAttributeType).
>
> So, long story short, every single datastore will generate attribute
> types stating that the geometry is required. This does not seem right
> to me, what do you think? I understand that for shapefiles, but it
> seems to be wrong for JDBC based sources, or for the property data store
> (I guess).
>
> Enter Geoserver and its DTO stuff. AttributeTypeInfo is a sort of
> wrapper around the actual attribute type, and its minimum
> occurrences is determined by something other than the actual
> attribute type in 1.5.x.
> DataTransferObject.create(schemaBase, AttributeType) contains:
> dto.setMinOccurs(isManditory(schemaBase, attributeType.getName()) ? 1 : 0);
>
> schemaBase is usually "AbstractFeatureType", that does not contain any
> attribute, as a result, every single attribute in geoserver gets
> configured as optional, no matter what the feature type says.
> This is obviously wrong for shapefiles geometries imho, at least
> on the write perspective, thought if we change
>
> In trunk, the story is a little different, because the code above says:
> if (isManditory(schemaBase, attributeType.getName()) ||
> (attributeType.getMinOccurs() > 0)) {
> dto.setMinOccurs(1);
> } else {
> dto.setMinOccurs(0);
> }
>
> I guess Justin had to change this to make WFS 1.1 cite happy.
>
> Now, I'm going to fix the postgis data store so that it takes into
> account attribute nullability (Justin, I'll wait for your get go
> to commit the patch), but it seems to me we have to fix somewhat
> the Geosever behaviour too...
>
> Cheers
> Andrea
>
>
> !DSPAM:1004,45f5257095731194215290!
>
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
