On Sunday 30 September 2012, Anssi Kääriäinen wrote:
>
> cur.execute("select case when dbms_random.random > 0.5 then 0.1
> else 0 end from testtable")
>
> Guess what is the type of the column? It is both Decimal and int,
> alternating based on the random result.
>
> This seems like surprisin
On Sunday 30 September 2012, Anssi Kääriäinen wrote:
>
> I walked into this one... But, sorry, I will not have time for this
> pull request for 1.5.
>
Ok, I can't say you didn't warn me this would be the case. Thanks a lot for
the time you did spend on it,
Shai.
--
You received this message b
On 30 syys, 01:24, Shai Berger wrote:
> > The problem seems to be that on Oracle, 1.1 is NUMERIC, and that is
> > something which _is_ a decimal in Python. We should not change that.
>
> > To me it seems the answer is to use to_binary_float/to_binary_double
> > in raw SQL queries. For example:
>
>
On 29 syys, 23:25, Anssi Kääriäinen wrote:
> I tested the pull request 393 (the speedup to ._rowfactory). Above
> test case, and the decimal case runs in around one second, the float
> case in 0.1 seconds. So, there is a regressions for decimals. On the
> other hand floats are way faster. Will in
Hi, and thanks for your attention. I know you must be extremely busy with
other issues of the feature freeze. I just want to make some things clear:
> Based on the above I am -1 on having a flag that interprets NUMBER
> fields as floats. There is already an Oracle data type to use for
> this.
>
On 29 syys, 21:51, Shai Berger wrote:
> On Sunday 23 September 2012, Anssi Kääriäinen wrote:> On 22 syys, 23:34, Shai
> Berger wrote:
> > There isn't much time to do feature additions. It is possible to get
> > the feature into 1.5, but you should not expect it to happen. As for
> > the feature
Hi, Sorry about the delay in writing this -- it was in my mind, but I forgot
to let it out...
On Sunday 23 September 2012, Anssi Kääriäinen wrote:
> On 22 syys, 23:34, Shai Berger wrote:
> >
> > [...] I will also include the extra setting in
> > the "options" dictionary (choosing if expressions
Hi all,
On Sunday 23 September 2012 15:05:21 Anssi Kääriäinen wrote:
>
> Doing final polish for Ian's patch and providing benchmark results for it
> will get this patch closer to commit.
>
I made some initial benchmarks, and they do not reflect the change I've seen in
the actual application. I
On Tuesday 25 September 2012, Ian Kelly wrote:
> On Tue, Sep 25, 2012 at 11:47 AM, Ian Kelly wrote:
> > Thanks for putting together a pull request. Please note the patch
> > will also need to update the documentation to state the new cx_Oracle
> > version requirement (was 4.3.1, now 5.0.1).
>
>
On Wednesday 26 September 2012 20:26:11 Andre Terra wrote:
> On Mon, Sep 24, 2012 at 9:41 PM, Shai Berger wrote:
> > While preparing the patch, I ran into the inspectdb regression test
> > suite; this suite includes, among other things, a model with a database
> > column named
> > 'prc(%) x', whic
On Mon, Sep 24, 2012 at 9:41 PM, Shai Berger wrote:
> While preparing the patch, I ran into the inspectdb regression test suite;
> this suite includes, among other things, a model with a database column
> named
> 'prc(%) x', which breaks test database creation on Oracle on current
> trunk. I
> in
On Tue, Sep 25, 2012 at 11:47 AM, Ian Kelly wrote:
> Thanks for putting together a pull request. Please note the patch
> will also need to update the documentation to state the new cx_Oracle
> version requirement (was 4.3.1, now 5.0.1).
Also, there should probably be something about this in the
On Tue, Sep 25, 2012 at 1:31 AM, Shai Berger wrote:
> On Sunday 23 September 2012, Anssi Kääriäinen wrote:
>> Doing final polish for Ian's patch and providing benchmark results for it
>> will get this patch closer to commit.
>>
> I had hoped the Django test suite alone will provide a convincing be
On Tuesday 25 September 2012 10:03:11 Anssi Kääriäinen wrote:
>
> Am I correct the benchmark is basically:
>
> cursor = connection.cursor()
> cursor.execute("some sql fetching many rows with NUMBER() columns")
> timer.start()
> for row in cursor.fetchall():
> pass
> print timer.used()
>
Yes,
On 25 syys, 10:31, Shai Berger wrote:
> On Sunday 23 September 2012, Anssi Kääriäinen wrote:> Doing final polish for
> Ian's patch and providing benchmark results for it
> > will get this patch closer to commit.
>
> I had hoped the Django test suite alone will provide a convincing benchmark,
> bu
On Sunday 23 September 2012, Anssi Kääriäinen wrote:
> Doing final polish for Ian's patch and providing benchmark results for it
> will get this patch closer to commit.
>
I had hoped the Django test suite alone will provide a convincing benchmark,
but apparently that is not the case -- on my lapt
On Sunday 23 September 2012 15:05:21 Anssi Kääriäinen wrote:
>
> If you decide to work on this, please split the patch into two: one
> for the ._rowfactory change, one for the feature addition. My belief
> is that the ._rowfactory change is going to be something we can very
> easily justify commi
On 22 syys, 23:34, Shai Berger wrote:
> On Wednesday 05 September 2012, Ian Kelly wrote:
>
>
>
> > Thanks for tracking that down. _rowfactory was a module-level
> > function rather than a method, and I should have left it that way.
>
> So -- Ian, Anssi, are you going to include the fix in Django
On Wednesday 05 September 2012, Ian Kelly wrote:
>
> Thanks for tracking that down. _rowfactory was a module-level
> function rather than a method, and I should have left it that way.
So -- Ian, Anssi, are you going to include the fix in Django 1.5? I can help by
either reviewing it for you or
On Tue, Sep 4, 2012 at 3:28 PM, Anssi Kääriäinen
wrote:
> I did some digging, and the reason for the error is this line in the
> patch:
> self.cursor.outputtypehandler = self._outputtypehandler
>
> What is happening is that self has a reference to self.cursor, which
> has reference to bound me
I did some digging, and the reason for the error is this line in the
patch:
self.cursor.outputtypehandler = self._outputtypehandler
What is happening is that self has a reference to self.cursor, which
has reference to bound method self._outputtypehandler, which has a
reference to self. Thus, t
On Tuesday 04 September 2012, Ian Kelly wrote:
> On Mon, Sep 3, 2012 at 6:14 AM, Shai Berger wrote:
> > On Wednesday 29 August 2012 22:17:22 Ian Kelly wrote:
> >> https://github.com/ikelly/django/commit/086f502a1c2acb9db27531f7df78cb9d
> >> f9a b83bd
> >
> > more subtle; either way, this is what
Resending to the list:
On Sep 4, 2012 11:44 AM, "Ian Kelly" wrote:
>
> On Mon, Sep 3, 2012 at 6:14 AM, Shai Berger wrote:
> > On Wednesday 29 August 2012 22:17:22 Ian Kelly wrote:
> >>
> >>
https://github.com/ikelly/django/commit/086f502a1c2acb9db27531f7df78cb9df9a
> >> b83bd
> >>
> > I've run a
On Wednesday 29 August 2012 22:17:22 Ian Kelly wrote:
>
> https://github.com/ikelly/django/commit/086f502a1c2acb9db27531f7df78cb9df9a
> b83bd
>
I've run a version based on this -- basically, porting the patch to Django 1.3
which we use (so, no tzinfo), using "float" as the default for expressions
On 30 elo, 23:24, Shai Berger wrote:
> Hi Ian, Jacob, Anssi and all,
>
> Thanks for the quick and positive responses.
>
> On Wednesday 29 August 2012, Ian Kelly wrote:
>
> >https://github.com/ikelly/django/commit/086f502a1c2acb9db27531f7df78c...
>
> > Shai, if you would be willing to try this patc
Hi Ian, Jacob, Anssi and all,
Thanks for the quick and positive responses.
On Wednesday 29 August 2012, Ian Kelly wrote:
>https://github.com/ikelly/django/commit/086f502a1c2acb9db27531f7df78cb9df9ab83bd
>
> Shai, if you would be willing to try this patch, I'd like to hear your
> results. Please
On 29 elo, 22:18, Ian Kelly wrote:
> There's another option that also hasn't been implemented, because it
> would mean dropping support for cx_Oracle versions older than 5.0.1.
> Perhaps the time has come to do that (I note that the oldest binary
> still listed at the cx_Oracle website is 5.1). T
On Wed, Aug 29, 2012 at 10:34 AM, Jacob Kaplan-Moss wrote:
> Hey Shai --
>
> Generally sounds like a good idea, I don't see why this shouldn't go
> in. You might want to wait until someone with more Oracle experience
> chimes in, but I'm having a hard time seeing why a number -> str ->
> number da
Hey Shai --
Generally sounds like a good idea, I don't see why this shouldn't go
in. You might want to wait until someone with more Oracle experience
chimes in, but I'm having a hard time seeing why a number -> str ->
number dance would be a good idea.
I'm generally adverse to introducing more se
Hi Django developers,
I've been working with Oracle on a project with some performance requirements,
and we've noticed long ago that the Django Oracle backend performs
significantly worse than other backends; we've been able to profile it and see
that, indeed, a lot of time is spent in processi
30 matches
Mail list logo
