On 14/12/11 14:56, Marko Kreen wrote:
> In 2.4.2 you shuffled numeric codes for isolation levels freely,
> because "everybody should be using symbolic codes".
>
> Generally that would be true, except this case: psycopg 1.x
> did not have symbolic codes, so numeric codes were
> part of public API. So old code that were written
> for psycopg1 will not work anymore with psycopg2.
>
> What makes is especially bad is that such code will not fail
> clearly, but instead will result in silent data corruption.
> We experienced that with Skytools.
>
> Also note that even in psycopg2, the .set_isolation_level()
> is part of core API, but the constants are under psycopg2.extensions.
> So even pure-2.x code may be using numerical constants.
>
>
> I suggest 2 ways to fix it properly:
>
> 1) Use numeric codes out of range compared to 1.x:
>
> ISOLATION_LEVEL_AUTOCOMMIT = 10
> ISOLATION_LEVEL_READ_UNCOMMITTED = 11
> ISOLATION_LEVEL_READ_COMMITTED = 12
> ISOLATION_LEVEL_REPEATABLE_READ = 13
> ISOLATION_LEVEL_SERIALIZABLE = 14
>
> and give errors to old codes - that would give clear detection
> that somebody is using old codes.
>
> 2) Use codes that are compatible with 1.x:
>
> ISOLATION_LEVEL_AUTOCOMMIT = 0
> ISOLATION_LEVEL_READ_UNCOMMITTED = 1
> ISOLATION_LEVEL_READ_COMMITTED = 1
> ISOLATION_LEVEL_REPEATABLE_READ = 2
> ISOLATION_LEVEL_SERIALIZABLE = 3
>
> the REP_READ=2, SER=3 change is deliberate, because before 9.1
> they were equal, and in 9.1+ the REP_READ corresponds
> to old SER. The SER level in 9.1 is new, and unlikely
> to be expected by old code.
>
> I would suggest even releasing 2.4.4 quite soon with
> this fixed, to avoid anybody else tripping on this bug.
You're right. I rather like (2) and I'll do the fix unless Daniele has a
very good reason to go with (1).
federico
