1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88
|
sqlobject (3.0.0+dfsg-1) unstable; urgency=low
Starting with SQLObject 3.0, SQLObject supports python 3. This is
provided by the python3-sqlobject package.
The helper applications sqlobject-admin and sqlobject-convertOldURI have
been moved to the sqlobject-admin package and the documentation
has been moved to the python-sqlobject-doc package.
The following behaviour changes between Python 2 and Python 3 are important:
* In Python 3, BLOBCol now accepts and returns bytes, rather than strings as
it did in Python 2.
* In Python 3, StringCol now accepts arbitrary Unicode strings.
* The dbEncoding parameter to UnicodeCol has no effect in Python 3 code,
as this is now handled by the underlying database layer. The parameter
is still available for those writing Python 2 compatible code.
Also note that, when using Python 3 and MySQL, the default encoding
on MySQL is "latin1", which can cause problems with general Unicode
strings. The SQLObject authors recommend specifying the character
set as "utf8" to avoid problems in this case.
For more information on the changes between Python 2 and Python 3,
see /usr/share/doc/python-sqlobject-doc/Python3.txt from the
python-sqlobject-doc package.
The helper applications use python 3 by default. If you need to run
them under python 2, you will need to explicitly specify the
python interpreter: "/usr/bin/python2 /usr/bin/sqlobject-admin <options>".
-- Neil Muller <drnlmuller+debian@gmail.com> Wed, 29 Jun 2016 13:21:56 +0200
sqlobject (2.1.2-1) unstable; urgency=low
Starting with SQLObject 2.0, DateTimeCol and TimeCol can read and write
values with microseconds.
Backward compatibility warning! Date/Time values created with microseconds
cannot be read back from SQLite databases (and perhaps other backends) with
versions of SQLObject older than 1.7.
SQLObject will not automatically switch to using microseconds for some
backends. In these cases, existing databases will continue to work as before,
using only second precision. The database can be manually updated to support
microseconds.
For microsecond support using MySQL or MariaDB, both the database and the
python-mysqldb client need to be new enough. Versions of python-mysqldb
before 1.3.1 don't support datetime columns with microseconds correctly.
Microseconds are supported by MariaDB since version 5.3.0 and by MySQL since
version 5.6.4, and even these versions require special handling: columns to
store microseconds have to be declared with precision 6: TIME(6),
DATETIME(6), TIMESTAMP(6). SQLObject does the right thing when creating a
new database but existing databases have to be changed: run something like
"ALTER TABLE name MODIFY COLUMN col TIME(6);"
for every column that you want to store microseconds.
For MSSQL use datetime2(6) and time(6) columns. They are available since
MS SQL Server 2008.
-- Neil Muller <drnlmuller+debian@gmail.com> Thu, 29 Oct 2015 10:53:32 +0000
sqlobject (1.4.1-1) unstable; urgency=low
Due to the large gap between updates to the sqlobject package, there
are a number of significant changes in this version.
All database signals are now sent with the instance or class as the first
parameter. The following signals were changed: RowCreateSignal,
RowCreatedSignal, DeleteColumnSignal
Post-processing functions for all signals are called now called with
the instance as the first parameter. The following signals were
changed: RowUpdatedSignal, RowDestroySignal, RowDestroyedSignal.
The DB URI parser was reworked to use urllib.split*() and unquote().
This means that any username/password/path are allowed in DB
URIs if they are properly %-encoded, and DB URIs are automatically
unquoted. The sqlobject-convertOldURI script can be used to correctly
quote an old DB URI.
The backend parameter in the DB URI was renamed to driver.
The dirty attribute has been moved from the SQLOBject base class to the
sqlmeta class
-- Neil Muller <drnlmuller+debian@gmail.com> Sat, 03 Aug 2013 14:55:07 +0200
|