« back to all changes in this revision
Viewing changes to docs/changelog.txt
- browse files at revision 1
- compare with another revision
- compare with revision 1
- download diff
- download tarball
- view history from revision 1
- Committer: Bazaar Package Importer
- Author(s): Matthias Klose
- Date: 2003-09-28 15:52:16 UTC
- Revision ID: james.westby@ubuntu.com-20030928155216-3o2xngislqrw1wnr
Tags: upstream-3.0.1
Import upstream version 3.0.1
added
removed
docs/changelog.txt
1
KInterbasDB Changelog
2
3
-----------------------------------------------------------------------------
4
3.0.1 versus 3.0.1_pre3
5
-----------------------------------------------------------------------------
6
BUG FIXES:
7
- Adjusted input handling of NULL values. The new scheme raises an
8
exception immediately when it detects that a Python None value has
9
arrived for storage in a database field or parameter that disallows
10
NULL values.
11
The old scheme simply accepted the Python None value and then tried
12
to execute the query, relying on the database API to detect the error.
13
With certain data types, the database API would silently insert a bogus
14
value rather than detecting the error.
15
16
- Scrutinized the datetime input/output facilities, found some
17
incompatibilities with the DB API, and corrected them. These changes
18
are backward-incompatible, but are warranted because the previous
19
behavior was in defiance of the specification. See further notes about
20
the nature of these changes in the backward-incompatibilities section.
21
22
- Fixed a memory leak that affected the storage of Python string input
23
parameters in BLOB fields.
24
25
- Fixed a rollback-related bug that arose if a connection to a database
26
was established, but a transaction was never started on that connection.
27
In such a case, a spurious exception was raised when the connection was
28
garbage collected.
29
Normal code would not have invoked this bug, but it was still a bug.
30
31
BACKWARD-INCOMPATIBILITIES:
32
- Datetime input/output has changed to better comply with the DB API (see
33
datetime bugfix discussion above).
34
Code that uses the mx.DateTime module directly (rather than the
35
kintebasdb DB API datetime constructors) should not be affected.
36
For details, see the comments in the code block in __init__.py tagged
37
with "DSR:2002.07.19".
38
39
-----------------------------------------------------------------------------
40
3.0.1_pre3 versus 3.0.1_pre2
41
-----------------------------------------------------------------------------
42
BUG FIXES:
43
- Bug #572326 (which was not present in kinterbasdb 3.0 and never affected
44
Python 2.2+) caused several numeric types to not be transferred from
45
Python to the database engine when they were passed as query parameters.
46
This was a serious bug; it caused even such fundamental operations as:
47
cursor.execute("insert into the_table values (?)", (1,))
48
to not work correctly.
49
50
-----------------------------------------------------------------------------
51
3.0.1_pre2 versus 3.0.1_pre1
52
-----------------------------------------------------------------------------
53
BUG FIXES:
54
- CHAR output now doesn't have such problems with multibyte character sets
55
and values shorter than the maximum declared length of the field.
56
CHARs are no longer returned with their trailing blanks intact. The
57
trailing blanks have been abandoned because they were in fact NULL
58
characters, not spaces. kinterbasdb would fill in the spaces manually,
59
except for the problems that approach causes with multibyte character
60
sets.
61
62
- Fixed a potential buffer overflow, but the fix only applies when compiled
63
against Python 2.2 or later.
64
65
BACKWARD-INCOMPATIBILITIES:
66
- See coverage of CHAR output changes in the 'BUG FIXES' section. In a
67
nutshell: CHAR output values no longer have trailing NULL bytes.
68
69
-----------------------------------------------------------------------------
70
3.0.1_pre1 versus 3.0
71
-----------------------------------------------------------------------------
72
NEW FEATURES:
73
- It is now possible to connect to a database under a specific role by using
74
the 'role' keyword argument of the kinterbasdb.connect function.
75
76
- The following methods now accept any sequence except a string for their
77
'parameter' argument, rather than demanding a tuple: Cursor.execute,
78
Cursor.executemany and Cursor.callproc.
79
80
81
BUG FIXES:
82
- kinterbasdb supports IB 5.x again.
83
Various identifiers specific to IB 6.x/Firebird had crept into unguarded
84
areas of __init__.py and _kinterbasdb.c, but this has been changed so
85
that kinterbasdb compiles gracefully with IB 5.x.
86
See:
87
http://sourceforge.net/tracker/index.php?func=detail&aid=553184&group_id=9913&atid=209913
88
89
- The distutils setup script no longer raises a ValueError on Windows 2000
90
or XP.
91
92
- The precision slot in Cursor.description was always zero. It now contains
93
the correct value if that value can reasonably be determined.
94
Note that the database engine records the precision of some fields as
95
zero (e.g., FLOAT), and the slot will also be zero in cases where the
96
database engine does not expose the precision of the field (e.g., dynamic
97
fields such as "SELECT 33.5 FROM RDB$DATABASE").
98
Since the database API does not provide the field's precision figure in
99
the XSQLVAR structure, it is necessary to query the system tables. In
100
order to minimize the performance hit, precision figures are cached per
101
Connection; the determination of a given field's precision figure in the
102
context of a given Connection will require only dictionary lookups after
103
it is determined the first time with a system table query.
104
An unfortunate side effect of this caching is that if a field's
105
precision is altered after the figure has been cached in by a Connection,
106
cursors based on that Connection will still show the old precision figure.
107
In practice, this situation will almost never arise.
108
See:
109
http://sourceforge.net/tracker/index.php?func=detail&aid=549982&group_id=9913&atid=109913
110
111
- On Linux, attempting to fetch immediately after having executed a
112
non-query statement resulted in a segfault. An exception is now raised
113
instead. The problem did not afflict Windows, which always raised the
114
exception.
115
See:
116
http://sourceforge.net/tracker/index.php?func=detail&aid=551098&group_id=9913&atid=109913
117
118
- The message carried by this exception grew without bound in on both
119
Windows and Linux. It no longer does.
120
121
- Under some circumstances, the fetched values of CHAR fields were
122
incorrect. CHAR values now appear as expected (they are left-padded with
123
spaces and always of length equal to their field's designated maximum
124
length).
125
126
- Cursor.fetchmany raised an error if there were no remaining values to
127
fetch. It now returns an empty sequence instead, as required by the DB
128
API Specification.
129
130
- Field domains are checked more strictly. It is now impossible to (for
131
example) issue a statement that attempts to insert a 12-character string
132
into a 10-character CHAR field without encountering an exception.
133
This checking is not perfect, since it validates against the field's
134
internal storage type rather than the field's declared type. For example,
135
a NUMERIC(1,1), which is stored internally as a short, will erroneously
136
accept the value 12.5 because 125 fits in a short.
137
138
- When operating in imprecise mode (connection.precision_mode == 0),
139
kinterbasdb 3.0 sometimes interpreted integer values as though it were
140
operating in precise mode.
141
142
143
-----------------------------------------------------------------------------
144
3.0 versus 2.0-0.3.1
145
-----------------------------------------------------------------------------
146
NEW FEATURES:
147
The new features are thoroughly documented in the KInterbasDB Usage Guide
148
(usage.html); they need not be reiterated here.
149
However, backward-incompatible changes *have* been documented in this
150
changelog (see the BACKWARD-INCOMPATIBILITIES section).
151
152
BUG FIXES:
153
Many bugs have been fixed, including (but not limited to) the following,
154
which were registered with the KInterbasDB bug tracker at SourceForge
155
( http://sourceforge.net/tracker/index.php?group_id=9913&atid=109913 ):
156
157
- 433090 cannot connect to firebird server
158
- 438130 cursor.callproc not adding param code
159
- 468304 fetchmany return all record
160
- 498086 ignores column aliases in select
161
- 498403 fetching after a callproc hangs program
162
- 498414 execute procedure message length error
163
- 505950 inconsistent fetch* return types
164
- 515974 Wrong decoding of FB isc_version
165
- 517093 broken fixed-point handling in 3.0
166
- 517840 C function normalize_double inf. loop
167
- 517842 fetch bug - program hangs
168
- 520793 poor DB API compliance
169
^ a *BIG* fix that entailed many changes
170
- 522230 error with blobs larger than (2^16) - 1
171
- 522774 inconsistent fixed-point conv in 3.0-rc2
172
- 523348 memory leak in Blob2PyObject
173
174
- immediate execution facilities unreliable in 2.x
175
176
BACKWARD-INCOMPATIBILITIES:
177
As a result of the changes required for some of the bugfixes (especially
178
#520793 - "poor DB API compliance") and general reengineering, several
179
areas of backward-incompatibility have arisen:
180
181
- fetch* return types
182
The standard fetch(one|many|all) methods now return just a sequence,
183
not a combined sequence/mapping. If you want a mapping, use one of
184
the fetch(one|many|all)map methods.
185
Note the "'absolutely no guarantees' except..." caveats in the
186
KInterbasDB Usage Guide regarding the return types of the
187
Cursor.fetch* methods and the contents of the Cursor.description
188
attribute.
189
This is a significant backward-incompatibility, and was not
190
undertaken without serious consideration (for evidence see
191
http://sourceforge.net/forum/forum.php?thread_id=622782&forum_id=30919
192
).
193
194
- Fixed point number handling
195
Fixed point number handling has been remodelled. By default, fixed
196
point numbers (NUMERIC/DECIMAL field values) are now represented
197
(with a potential loss of precision) as Python floats.
198
A Connection.precision_mode attribute has been added so that precise
199
representation of fixed point values as scaled Python integers (as in
200
KInterbasDB 2.x) can be used at will.
201
For more information, see the KInterbasDB Usage Guide.
202
203
- Connection.dialect
204
In KInterbasDB 2.x, the default connection dialect was 1 (the
205
backward-compatibility dialect for use with Interbase 5.5 and earlier).
206
KInterbasDB 3.0 is being released into quite a different climate.
207
Interbase 6.0 was released nearly two years ago, and Firebird 1.0 has
208
recently been released. Because it is expected that KInterbasDB 3.0
209
will be used most frequently with Interbase 6.0+ and Firebird, the
210
default connection dialect is 3.
211
Using KInterbasDB 3.0 with Interbase 5.5 and earlier is still
212
possible, though untested by the developers of KInterbasDB 3.0. See
213
the Connection.dialect documentation in the KInterbasDB Usage Guide
214
for an explanation of how to initialize a connection with a dialect
215
other than 3.
216
217
- Connection.server_version
218
The Connection.server_version attribute is now a string rather than
219
an integer. An integer simply was not expressive enough to represent
220
the numerous Interbase variants that exist today (including Firebird,
221
which does not fit neatly into the Interbase version progression).
222
For more information, see the KInterbasDB Usage Guide.
223
224
- kinterbasdb.execute_immediate
225
The kinterbasdb.execute_immediate function has been removed. A
226
similar function named kinterbasdb.create_database has been added.
227
The primary differences between kinterbasdb.execute_immediate and
228
kinterbasdb.create_database are:
229
- kinterbasdb.create_database is not as general
230
- kinterbasdb.create_database actually works
231
232
The execute_immediate method of the Connection class has been
233
retained.
234
For more information, see the KInterbasDB Usage Guide.
235
-----------------------------------------------------------------------------
b'\\ No newline at end of file'
Loggerhead is a web-based interface for Breezy
Version: 2.0.1