Thanks for forwarding my reply to geotool-devel, I am going to have to give up use of my refractions email address (this is too silly not being able to send email from home). Perhaps next week when I have a new ISP I will be able to send email from home...
Andrea Aime wrote: >> As for the new feature model; it is a good thing we don't validate >> features before adding them :-) >> >> So there are a couple of ways to take your question: How do you want to >> communicate the fact that these values are not actually required during >> creation (for user interface developers?) Perhaps just let the Datastore >> ignore these values durning creation. >> > That would not be completely correct. If a user inputs a non null > value manually it shall be accepted. "serial" is just an indication > of a method to generate the default value when the user did not > explicitly provided one. If in the db you try to insert NULL you'll > 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. >> I assume that after you create the feature the user should not be >> modifying these values using an update? If so you have a strong case for >> a "read-only" attribute that is non-nullable. >> > No, you're reading too much into this. Not even the primary keys have > this requirement. I agree a way to make a primary key attribute read > only is interesting, but it's out of topic her. > Have a look at the underlying dbms, even for primary keys generated > with serials, you are still able to modify the value. > I don't have time to look at the dbms right now Andrea, I will simply take your word for it :-) Well the idea with the placing "client properties" as part of our FeatureType data structure is to let DataStores and Client code set up additional lines of communication (previously they always used a Map<FeatureType,value> and keeping these look aside tables in sync was a pain... with my architecture hat on I would encourage you to experiment for both of these problems; and then see what solutions you came up with, and what solutions actually worked. This advice (using client properties) is more in keeping with the read-only attribute concept, for simply not providing a value I would ask you to use the general feature model. You could even use the general Feature class for creation; and then read the values back using SimpleFetaure (after the database has filled in the blanks). Is stepping beyond the bounds of SimpleFeatureBuilder going to be okay for you? Note even if you use your own "builder" and remember what values have been set you will be able to tell the difference between "null" and "unset", just store the attributes as they are provided to you (rather than just stripping out the values into an array as is done now). >> It sounds like this is a real requirement from the database side of >> things; how would you handle this situation using WFS/GML right now? >> > Well, I don't know, that's why I'm asking. In XML you have two ways > to specify that an element is missing, namely not specifing the > element at all, or using <element/>. But how do you specify that > an element is null? Or else, does it make sense to map one xml > way to null and the other to missing? > Finally, don't we lack the distinction in the feature model anyways? > We can do exactly the same thing. > We could treat this at the datastore level, but we really miss something > there. Consider the two following declarations, both valid in a dbms: > blah serial; > blahNull serial nullable; > Yes got it, thanks for the example. > Both first and second generate a value when you don't specify one. > But the second also accepts a null as an explicit value. > So it seems to me that in order to handle both cases we'd need > the feature model to have a separation between the lack of value > and the null value. Once you have that, we still have to decide > how to map xml into missing or null... seems like a tough issue. > This should all be fine; but you starting to step outside of the bounds of SimpleFeature. Please enjoy the ride :-) Jody ------------------------------------------------------------------------- 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
