IntegerField and SmallIntegerFields maps to the same db type on Oracle.

[Michał Nowotka]

Does anyone knows the reason why IntegerField and SmallIntegerFields both map to NUMBER(11,0) in Orcale?
I would expect SmallIntegerFiled map to something smaller ;)

[Ian]

On Thursday, December 13, 2012 4:29:30 AM UTC-7, Michał Nowotka wrote:

Does anyone knows the reason why IntegerField and SmallIntegerFields both map to NUMBER(11,0) in Orcale?
I would expect SmallIntegerFiled map to something smaller ;)

Beats me.  Although note that Oracle itself equates both INTEGER and SMALLINT to NUMBER(38), so at least there's precedent.  I expect NUMBER(11) was picked as a reasonable-looking compromise.

[Michał Nowotka]

I agree, but if you map SmallIntegerField to say NUMBER(9) you will save some space, correct? 

[Tom Evans]

On Thu, Dec 13, 2012 at 4:50 PM, Michał Nowotka <mmm...@gmail.com> wrote:
> I agree, but if you map SmallIntegerField to say NUMBER(9) you will save
> some space, correct?
>

Oracle may use the exact same datatype underneath for all NUMBER
(speculation). The value in brackets could simply be the default
number of digits presented.

Cheers

Tom

[Michał Nowotka]

OK, then why django makes a difference between BigIntegerField (maps to NUMBER(19)) and IntegerField (maps to NUMBER (11)).
Thinking this way BigIntegerField, IntegerField and SmallIntegerField should all map to NUMBER(39).

[Chris Cogdon]

According to the docs, oracle uses 1 byte for the magnitude, and 1 or more bytes for significant digits.

HOWEVER, it assigns that space dynamically, so even if you say NUMBER(11), you will still only need 2 bytes to represent the number "5". All NUMBER(11) gives you is some range checking on input.

So, from that, I read that there's no real benefit from using SmallIntegerField, since it'll still only take up as much space as you need. Any range checking can be done in the Model's save method, or a Form's clean methods, and be much more specific to the application's requirements than oracle's range checking can provide.

[Karen Tracey]

On Thu, Dec 13, 2012 at 1:19 PM, Michał Nowotka <mmm...@gmail.com> wrote:

OK, then why django makes a difference between BigIntegerField (maps to NUMBER(19)) and IntegerField (maps to NUMBER (11)).

BigInteger was added after the others, probably by someone who did not notice/understand why the other two were defined as they were. When testing out that patch for inclusion I focused on "does the new field accept the range of numbers it should" and likely didn't check to make sure the new type defined for each backend was consistent with how other types in that backend had been specified...

Karen
--
http://tracey.org/kmt/