On Thu, Dec 18, 2014 at 7:39 PM, M.-A. Lemburg wrote:
> On 17.12.2014 19:13, INADA Naoki wrote:
>> As I said before, prepared statement is normally bound to connection.
>> So `.prepare()` method should be connection's method, not cursor's.
>>
>> prepared = conn.prepare("SELECT ?+?")
>> ...
>> cur
>
> In my experience, caching of prepared statements in modern use is not a major
> source of performance gain unless your application overall is already
> blindingly fast, more than Python typically provides. Consider that a site
> like reddit.com serves six billion page views a month from Po
On Thu, Dec 18, 2014 at 9:33 PM, M.-A. Lemburg wrote:
> On 18.12.2014 12:27, INADA Naoki wrote:
>> On Thu, Dec 18, 2014 at 7:39 PM, M.-A. Lemburg wrote:
>>> On 17.12.2014 19:13, INADA Naoki wrote:
As I said before, prepared statement is normally bound to connection.
So `.prepare()` meth
> Can someone please take up this task and prove to me with benchmarks that
> this effort will be worthwhile
> (or at least show me what I’m going to have to put into my documentation as
> to when these new APIs are appropriate) ?
Some database software supports the processing of prepared SQL s
Hello!
I'm pleased to announce version 2.0.0, the first stable release of branch
2.0 of SQLObject.
What's new in SQLObject
===
Features & Interface
* DateTimeCol and TimeCol can read and write values with microseconds.
WARNING: microseconds are suppo
