On Sunday 27 April 2008 07:43:01 pm Jody Garnett wrote: > > get an exception. To have the serial behaviour trigger, you have to > > avoid specifying the value. > > But in our feature model we don't have the idea of "empty", > > "unspecified", right? > > We do; simply don't include that attribute when creating the feature; > (notice the distinction between not including and attribute and > including the attribute with a value of NULL ). Please note that this > falls outside the "SimpleFeature" concept - where every attribute bust > be accounted for in a prescribed order. > just a quick chim in on this one.. when client code calls addFeatures and the features being added are of a "subtype" of the original FT, one would expect the SQL INSERT statement to contain only the properties available in the incomming feature type, plus PK fields if needed, etc. Instead, the JDBC datastores grab a FeatureWriter with the _original_, _full_, feature type, and that's why "unespecified" attributes in the incomming features are being added either with an explicit NULL value, or with a default value when they're not nillable.
Now, making the jdbc datastores to create an insert with only the provided attributes would make the serial attribute case just work, but would break the case where a non nillable attribute is not explicitly specified. Gabriel ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
