Hi Andrea, Turning off validation at construction time is something that I generally think everyone agrees with. And is something that is there simply as a sanity check while switching to the new model. So it should not be an issue to turn it off.
As for the default value... if we do in fact *not* set a value when the attribute is non-nillable, i believe that breaks the rules of the feature model. I would suggest we proceed in one of two ways: 1) we open a debate about whether default value is useful in the model, and take it out if need be. Gabriel has some good insight on this one. 2) we add a flag to SimpleFeaureBuilder to allow the versioning datastore to change the behavior, and ignore the default even for non-nillable attributes. If we do that will that fix your issue? -Justin Andrea Aime wrote: > Hi, > today I've run for the first time in a couple of months > the versioning datastore unit test and found, to my dismay, > that lots of the were failing. I'm pretty sure I made > the versioning datastore work back after FOSS4G, yet > the issues I've found are pretty old so I'm confused... > > Anyways, all the issue come down to the fact that > it's no more possible to the if an attribute was set > by the user code or not. This is due to a few > items in the feature type and feature creation code: > a) SimpleFeatureBuilder forces the default value on > all non nillable feature attributes, that is, if > the user did not provide a value, the default > is forced down the throat of the feature > b) AttributeImpl does verify that the attribute value > is valid on construction > > a) seems like legitimate behaviour, but in fact imho it's > not. Picture this case: you have a table with a serial > primary key (auto-generated), and you want to include the > pk among the attributes (I need that for the versioning > to work and it's an option in the API anyways) > The feature gets built, the pk value is not provided, > as a result a default is stuck in. When it's time to > write on the db, the code sees the pk is already set, > so it does not try to generate it. > > In fact I have a couple of places in versioning where > this occurs, and one in the text feature builder. > > Now, I could make simple feature builder not force > in the defaults, but that would break right away > since the pk is not nillable so feature validation > will break. If I remove validation too > > Besides the technical details of why versioning > does not work, I think that: > * it should be possible to build invalid features, > they have to be valid when saved, but not during > their life in memory > * if the user does not provide a value, none should > be forced into the feature, otherwise it becomes > impossible to say what was set, and what is not. > > To recap, the current behaviour breaks a peculiar > code (one where the pk are mapped as attributes), > but I don't really know how to fix my code > without restoring the 2.4.x behaviour... I mean, I really > need to know if an attribute value was set or not, > and the current code makes it impossible to judge... > > An alternative could be to mimic EMF, and provide > an isSet() method used to check if the value was actually > provided (and the value accessor can return the default > if a value was not provided, in that case). > > Opinions? > Cheers > Andrea > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > !DSPAM:4007,47d01c02197741804284693! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
