Jody Garnett ha scritto: > That is pretty magic; so it *acts* a Nullable value during creation; but > after creation it is supposed to not be null. Sounds like the same kind > of relationship we have with FeatureId, you need to ask the database > what was actually stored (rather than just assume what you provided was > accepted as is)...
Yep, in fact "serial"/"auto increment" types are usually used to generate primary keys, but nothing in the dbms prevents you to use them as normal attributes (like the user in that jira issue is doing). > 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? > 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. > 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 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; 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. Cheers Andrea ------------------------------------------------------------------------- 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
