I am of two minds; - You have a much better chance of giving a good error message if you check using a restriction; and the restrictions can be used by user interfaces to catch the error early at a location where it will do a user some good. - I am sure you have a deadline to meet so hack on :-)
Cheers, Jody > ha, agreed > yet databases tend to keep putting that restrictions on fields... > would it be better to ignore that? I've no a strong opinion for the floating > point case... though wouldn't be against ignoring it and wait for the > database > to complain if someone has to do it > > Gabriel > > On Thursday 22 November 2007 10:49:26 pm Rob Atkinson wrote: > >> Surely the problem is that "length" is not a meaningful restriction on >> a floating point number... >> >> no amount of logic can resolve an inconsistency in your starting >> assumptions, maybe you need to validate the validation rules first! >> >> RA >> >> On Nov 23, 2007 2:56 AM, Gabriel Roldán <[EMAIL PROTECTED]> wrote: >> >>> Hi, >>> >>> I'm getting trapped by validation. Thing being that AttributeImpl >>> constructor calls Types.validate(this, getValue()), which fails to >>> validate, for example, a double value. >>> Example: >>> I've inserted a double attribute in sde with the value 0.7 >>> The attribute has a length "restriction" (aka, Filter) of 15. >>> Now, when I fetch the attribute from the database, it's >>> 0.700000000000001, hence the validation fails. >>> >>> Question is: >>> - does anybody got trapped in the same way? how to solve it? >>> - should I check the attribute content is valid before creating the >>> Attribute? - should that kind of validation not occur at all when >>> fetching data, but just when inserting/modifying? >>> >>> hrmmm... >>> >>> Gabriel >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Geotools-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Geotools-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> >> !DSPAM:4045,4745f96d82772090977483! >> ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
