Am Freitag, den 31.03.2006, 09:25 +0000 schrieb Malek:
> hmmm, on second thoughts, the whole checking in appserver would add a
> redundant overhead (even if slight) cause the db does the check
> anyway.

Different backends do different checking. There may be backends that
raise an error on too long strings, other backends might silently cut
it, and others (like csv or maybe even sqlite) could just save the whole
string even though it was declared with a shorter length.

So it might well make sense to not rely on the backend doing proper
checks, and the overhead we add is really minimal.

Thanks,
Reinhard

Am Freitag, den 31.03.2006, 08:10 +0000 schrieb Malek:
> raise an error?

This might be problematic where floating point handling generates values
like 12.3000000001 which is really 12.3

hmmm, on second thoughts, the whole checking in appserver would add a redundant
overhead (even if slight) cause the db does the check anyway.

there only is a pb when using std number types from backend.
example:

when in gcd we have number(2), we end up using a smallint (i believe it's db
dependent). So where we expect to have a limit of +99/-99, we have +32767/-32767.

The obvious solution would be to avoid that, by always creating a numeric type
(for our example numeric(2,0)). But , as johannes pointed out, a numeric will
always take much more storage size than any int equivalent (5 times more for the
example).

So maybe we could find a compromise, only do the appserver cheking for cases
where we know there could be a pb (ie bigint, integer and smallint).

lekma

warning: i may be completely wrong

raise an error?

from the xul client pov, i forbid such feeding by not allowing decimal
part longer than scale.

the pb is more sensitive in procedures, when you start to round up/down
rounded up/down computed values, you end up with results that will seem
suspicious to the vigilant accountant. :)

raise an error?

from the xul client pov, i forbid such feeding by not allowing decimal
part longer than scale.

the pb is more sensitive in procedures, when you start to round up/down
rounded up/down computed values, you end up with results that will seem
suspicious to the vigilant accountant. :)

On Fri, 2006-03-31 at 07:43 +0000, Reinhard Mueller wrote:
> Reinhard Mueller <reinhard@gnue.org> added the comment:
> 
> Am Freitag, den 31.03.2006, 06:33 +0000 schrieb Malek:
> > > and would probably even round numbers to the allowed fractional part
> > i believe this one should be avoided, you can mask user/input errors by
> > rounding.
> 
> So what would you propose if a property defined as number(3,1) is fed
> with 12,34 ?
> What if it is fed with 12,000000001 ?
> 
> _________________________________________________________
> GNUe issue tracker <gnue_issue_tracker@gnuenterprise.org>
> <http://www.gnuenterprise.org/roundup/gnue/issue95>
> _________________________________________________________

Am Freitag, den 31.03.2006, 06:33 +0000 schrieb Malek:
> > and would probably even round numbers to the allowed fractional part
> i believe this one should be avoided, you can mask user/input errors by
> rounding.

So what would you propose if a property defined as number(3,1) is fed
with 12,34 ?
What if it is fed with 12,000000001 ?

> and would probably even round numbers to the allowed fractional part
i believe this one should be avoided, you can mask user/input errors by
rounding.

Currently, the routine to set values in appserver only tests if the provided
value can be converted to the correct data type (i.e. whether it is a valid date
etc.). Neither strings nor numbers are checked for length. Handling too long
strings or too big numbers is completely left to the backend.

It would be preferrable if appserver tested for length of strings, for length of
numbers and would probably even round numbers to the allowed fractional part
before passing the data to the backend.