Roundup Tracker - Issues

Issue 2550549

classification
Postgres error on message templating
Type: behavior Severity: normal
Components: Versions: 1.4
process
Status: closed fixed
:
: rouilj : ajaksu2, rouilj
Priority: normal : patch

Created on 2009-05-26 19:40 by ajaksu2, last changed 2016-06-19 02:53 by rouilj.

Files
File name Uploaded Description Edit Remove
postgress_large_nodeid.diff ajaksu2, 2009-05-26 19:40 Fix for this error.
Messages
msg3709 Author: [hidden] (ajaksu2) Date: 2009-05-26 19:40
This is a test issue for the error it tries to fix :)
msg3710 Author: [hidden] (ajaksu2) Date: 2009-05-26 19:41
OK, now, Roundup, have you heard of version 123123123123 or issue
32132132131?
msg5344 Author: [hidden] (rouilj) Date: 2015-07-06 00:26
The test case in msg3710 returns a plain


   There is no issue with id 32132132131 

error, so the question is is this patch needed in the current
roundup? Maybe the underlying issue that caused postgres to fail
is fixed?

(or Maybe roundup.org isn't using postgres so there is no way to
reproduce the original error using it).

Also this patch seems to be getting applied at the wrong level.
If postgres is choking on id's larger than 2^30, shouldn't
this patch be in the postgres database back end so that

   if not cl.hasnode(id):

returns false?
msg5609 Author: [hidden] (rouilj) Date: 2016-06-19 02:15
Some background for this is:

https://hg.python.org/tracker/roundup/rev/eb3be57f1ef2

which is a patch at the templating level

or this patch that applies to rdbms_common.py

https://hg.python.org/tracker/roundup/rev/1548763e8273

but this patch returns id 0. I think it should return a value error
exception.

The Link type is declared as a SQL INTEGER which is 2^31-1 for both
mysql and postgres. SqLite's value is higher (up to 8 bytes) and python
should be able to int(8), but limiting it to the size of int(4) is
reasonable at this point.

It does impose a maximum of 2,147,483,647 items of any type in the rdbms
database.
msg5610 Author: [hidden] (rouilj) Date: 2016-06-19 02:53
Put in patch with a print statement to trace execution.
I changed demo to use sqlite and navigated to:

 http://localhost:9017/demo/issue2147483647

reported that there was no such id, print statement did not trigger.

 http://localhost:9017/demo/issue2147483648

reported that there was no such id and the print statement
within the max id patch in rdbms_common.py was printed.

 http://localhost:9017/demo/issue2147483649

reported that there was no such id and the print statement
again was triggered to prove the patch was triggering.

Committed on: 2b551b6b0830 without the debugging print statement.

This obsoletes:

https://hg.python.org/tracker/roundup/rev/eb3be57f1ef2 and
https://hg.python.org/tracker/roundup/rev/1548763e8273

Closing.
History
Date User Action Args
2016-06-19 02:53:13rouiljsetstatus: new -> closed
priority: normal
resolution: fixed
messages: + msg5610
assignee: rouilj
2016-06-19 02:15:32rouiljsetmessages: + msg5609
2015-07-06 00:26:07rouiljsetnosy: + rouilj
messages: + msg5344
2009-05-26 19:41:37ajaksu2setmessages: + msg3710
2009-05-26 19:40:50ajaksu2create