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 > Can you remove that "functionality"; two reasons: - the feature should be what the user has provided - default value is available for user interfaces etc... - invalid data should be tolerated, user can check if they care > b) AttributeImpl does verify that the attribute value > is valid on construction > - understood > 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. > Actually you have two suble differences of "valid" here: a) Valid against the feature type; frankly if the user wants to save data that does not meet the Featuretype restrictions it may in fact be possible. Consider the case where the restrictions are provided by a Filter (rather than the harder case of NULL) b) Valid against the data format; the database constraints would be harder to dodge; the DataStore itself could subst in the default value (since it knows the hard requirements of the database table and has access to the default value); or it could just throw an illegal attribute exception... > 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... > It may not be possible to judge given the existing api -- attributes can be set to null after all. This was not a requirement when we put together the feature model. > 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). > I had thought of this in another direciton; as an optimzation for FeatureWriter - creating a wrapper around the origional feature that tracks an isDirty flag associated with each attribute. You may also be able to use client properties.
Jody ------------------------------------------------------------------------- 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
