Hi Michael,
Thank you very much for your response :)
The problem is that numpy requires a list of tuples, just what the
low-level cursor provides.
I just wanted to avoid the conversion to dict and back again to a tuple.
Thank you very much!
2013/4/29 Michael Bayer
>
> On Apr 29, 2013, at 9:49
Hi Michael,
On 29/04/2013 19:58, Michael Bayer wrote:
I don't know what "wx.GetApp().ds" is, but a "commit", assuming this is a
Session, will return the current connection back to the connection pool, and any session changes
stay with that connection. Using the Session again will pull up a po
Hmmm, it looks interesting also! I'm just using the postgres version of
your previous solution, and modified / added some features, so pg type
ARRAY could be used with labels and to specify a maximum recursion level
(let's say, do not go more then 10 levels (not relative to start_node,
still)).
I don't know what "wx.GetApp().ds" is, but a "commit", assuming this is a
Session, will return the current connection back to the connection pool, and
any session changes stay with that connection. Using the Session again will
pull up a potentially different connection.
if you want to make per
On 04/25/2013 11:17 AM, Richard Gerd Kuesters wrote:
Well. I'm pretty interested :) I did find your solution very flexible, thou.
Thanks a lot,
Richard.
For completeness, here is a pure sqlalchemy version of the same
recursive ideas:
def _hierarchy():
# TODO: check if objec
Mike, I know that's the *supposed* behaviour. I'm just telling you that
when I have stream_results enabled, I get errors on create_all() /
drop_all() :-)
Cheers,
Richard.
On 04/29/2013 02:06 PM, Michael Bayer wrote:
Well stream_results is only valid with a SELECT statement. To use PG
serve
On Apr 29, 2013, at 9:49 AM, Pau Tallada wrote:
> Hi,
>
> I have some very big datasets that we want to process in batches of
> reasonable size.
> In order to do that, we enable the 'stream_results' execution option
> (available in Postgresql) and we use the fetchmany method to retrieve the
Well stream_results is only valid with a SELECT statement. To use PG server
side cursors as much as possible, what you need to do is do create_engine()
with server_side_cursors=True which will take effect for any SELECT statements,
but not any CREATE/DROP/INSERT/UPDATE/DELETE. This is a PG sp
Well, just to add: if I run my application (using psycopg2) with
stream_results=True, I get some weird errors also; even on create_all()
or drop_all() commands, which I think are pretty basic. Or is it mixing
the commands and not executing in order?
On 04/29/2013 01:55 PM, Michael Bayer wrote
Well seems like the "stream_results" feature must be extremely unpopular
because I can confirm this behavior even using connection-local execution
options, in 0.7 also.This feature is tested so will have to see exactly
what's up with those tests.
On Apr 29, 2013, at 9:49 AM, Pau Tallada w
Hi,
I think I fixed it but don't understand at all why my change would fix it.
getcont = "select rdb$get_context('USER_SESSION',
'LANGUAGE_ID') \
from rdb$database"
setcont = "select rdb$set_context('USER_SESSION',
'LANGUAGE_ID', %s) \
from rdb
Hi,
I have some very big datasets that we want to process in batches of
reasonable size.
In order to do that, we enable the 'stream_results' execution option
(available in Postgresql) and we use the fetchmany method to retrieve the
records in batches.
With those records we must build a numpy array
On 29/04/2013 15:05, Mauricio de Abreu Antunes wrote:
I know my question is very weird, but Have you ever tried the same SQL
string in the firebird console?
Not weird at all.
I use IBExpert for this and when I do it in a session all works fine.
Just to expand, all this is used by views for I18
I know my question is very weird, but Have you ever tried the same SQL
string in the firebird console?
2013/4/29 Werner
> On 29/04/2013 13:29, Werner wrote:
>
>> Hi,
>>
>> I am using the above to set the user language and I am sure this worked
>> for me, but it doesn't any more, in the mean tim
On 29/04/2013 13:29, Werner wrote:
Hi,
I am using the above to set the user language and I am sure this
worked for me, but it doesn't any more, in the mean time I upgraded to
0.8.1 (was on 0.7.8) and I wonder where things changed.
In a simple test like this it still works:
session.execute("
Hi,
I am using the above to set the user language and I am sure this worked
for me, but it doesn't any more, in the mean time I upgraded to 0.8.1
(was on 0.7.8) and I wonder where things changed.
In a simple test like this it still works:
session.execute("select rdb$set_context('USER_SESSION
16 matches
Mail list logo
