Oracle patch with VARCHAR2 max length 2000 CHARS

My patch for 1.1 with some new feature added (Import will recognize priamry keys columns)

I thought about the VARCHAR2 issue and would be the best way to let the user choose which unit will be used by default (bytes/chars) for VARCHAR2 columns. There should be an attribute for it.

So I create probably the last patch on this topic. It adds new way of hadling integers in Oracle DataDict described above. It also adds new feature - primary key recognition.

If the user will want to choose the unit of length at CHAR|VARCHAR2 while exporting with $conn->setParam('char_unit', 'BYTE|CHAR'); and VARCHAR2 definition will be exported with the unit VARCHAR2(10 CHAR) instead of the default VARCHAR2(10)`.

Please, review my latest patch and set status Commit approved on this ticket ;-)

If this patch will be approved, it will be good to know the place, where can we document at least new length of integers in oracle.

Patch waiting for commit approval

Commit this to both 1.0 and 1.1. Be sure that all tests pass and double check your code to make sure it is not introducing new bugs.

I have moved this to 1.0.6. We need confirmation that applying the patches doesn't break anything. If all is well then we can include this in 1.0.6 and 1.1 branch.

Sorry, that I haven't responded earlier.

I am sure, that this can't break anything.

This patch makes the oracle integers be "bigger" not smaller. So If someone have defined integer(1) and want it be NUMBER(1), after applying this patch it will be NUMBER(3). But I think, that this change is quite significant, so it should be moved only to 1.1 branch and I think it need some lines in what's new in 1.1 or documentation.

The main idea of this patch is to be compatible with other databases. I think, that many devs using doctrine are also using symfony and it's plugins that are mainly tested on MySQL. So there is no chance to have for example more than 9999 sfGuardUsers in Oracle now (yes, the column should be extended in db manually, but this is not the reason why we want to use doctrine, to work manually).

If somebody rely on the number size and needs eg. NUMBER(1) it should be defined as type: decimal, length: 1, scale: 0 and it generates NUMBER(1,0). I know that this isn't the best practice.

It will be quite good to know the opinion of other devs using oracle on this topic, but I wrote to few of them that are postig oracle specific bugs, but I didn't get any response.

Maybe there should be another way: a compat attribute for Oracle driver that will cause this behavior, or something else. But I am not familiar with the attributes in doctrine core.

We can include this in 1.2 but now the patch won't apply. Can you adjust and reattach for the 1.2 branch. Also, delete all the old patches so nobody is confused as to what patch is the latest. You can commit these changes to 1.2 yourself.

Fixed in r5938

I'm pretty sure that the mappings from Doctrine types to Oracle are true for UNSIGNED types only. For every unsigned max value starting with a 1, halving the max value will yield one precision less, because that suffices.

From the table

integer(1) to NUMBER(3) // max value 255 in unisgned TINYINT in MySQL
integer(2) to NUMBER(5) // max value 65535 in unsigned SMALLINT
integer(3) to NUMBER(8) // MEDIUMINT 16777215
integer(4) to NUMBER(10) // INT 2147483647
integer(8) to NUMBER(20) // BIGINT 18446744073709551615

this affects integer(3) and integer(8). So, for any SIGNED types, which should be the default (because standard SQL doesn't even know unsigned types), the precision should be:

integer(1) to NUMBER(3)  //127
integer(2) to NUMBER(5)  //32767
integer(3) to NUMBER(7)  //8388607
integer(4) to NUMBER(10) //2147483647
integer(8) to NUMBER(19) //9223372036854775807

Don't know how much this affects the solution. I didn't want reopen it.