On Tuesday, September 29, 2015 at 5:54:03 PM UTC+2, Michael Bayer wrote:
>
>
> On 9/29/15 9:50 AM, Ralph Heinkel wrote:
>
> In short this looks like:
>
> SELECT val
> FROM some_table
> ORDER BY val
> OFFSET 4 ROWS FETCH NEXT 4 ROWS ONLY;
>
> it's like
Hi everybody,
oracle 12c has received the long awaited possibility to properly provide
LIMIT and OFFSET parameters to a select query.
See
https://oracle-base.com/articles/12c/row-limiting-clause-for-top-n-queries-12cr1
for details.
In short this looks like:
SELECT val
FROM some_table
Hi Michael,
thanks for the prompt response and your directions. This was really
helpful. I will start as you've described in your reply.
Ralph
On Wednesday, April 8, 2015 at 6:19:27 AM UTC+2, Michael Bayer wrote:
On 4/7/15 1:59 PM, Ralph Heinkel wrote:
Hello dialect experts,
what
Hello dialect experts,
what would be the best approach for creating a SqlAlchemy dialect for a new
database system?
Are there any recipes available for this area, or is the way to go to read
code of existing dialects and derive my own dialect from those?
I had a first glance at some built-in
The latter was my favorite, but this seems to fail with
[...]
File
/usr/local/lib/python2.7/site-packages/SQLAlchemy-0.5.8-py2.7.egg/sqlalchemy/sql/expression.py,
line 1390, in in_
return self._in_impl(operators.in_op, operators.notin_op, other)
File
Hi everybody,
I've banging my head against this for hours ... maybe someone can help?
For a mapped class called 'Person' I'm trying to do something like:
query(Person).filter(Person.status_id.in_('select status_id from
myschema.mytable where statusname=:n1', n1='hired'))
Obviously this does
Hi,
we are about fitting pylint's configuration to work with out software. One
problem area is when we access SA models. Due to all attributes being set
dynamically pylint assumes that we want to access non-existing attributes
and reports either E1101 or E1103 error codes.
Does anyone have
Hi,
can anybody explain to me why the update statement on conn1 below is
not rolled back? conn2 should be in autocommit mode, but why does it
commit transactions of conn1?
Any help could be appreciated.
Thanks
Ralph
---
from sqlalchemy import *
engine =
Hi Michael and others,
we are about upgrading from SA 0.5 to SA 0.6, and some of our code is
failing because it was expecting to obtain a transaction obj from
engine.begin() (for threadlocal engines). In SA 0.4 this even returned
a context manager so that we were able to do
with
Hi Michael,
this drop-in is great, it does exactly what I need. It just has a
small problem in that the variable 'rownum' is not allowed in oracle,
it produces a
DatabaseError: (DatabaseError) ORA-00923: FROM keyword not found where
expected
Replacing 'rownum' with 'ora_rn' or something similar
Some months ago I had started a discussion about the ROW_NUMBER() OVER
support being dismissed from SA since 0.5.x (http://groups.google.com/
group/sqlalchemy/browse_thread/thread/74a8213886de6aeb/
25ee22fd71015485)
In our case we have queries being more than 6 times slower (30sec) if
On Dec 7, 6:06 pm, Michael Bayer mike...@zzzcomputing.com wrote:
I hadn't planned any future 0.5 releases, 0.7 is almost ready for betas.
What are the incompatibilities you have with 0.6 ?
One example is that Numeric(x,y) in oracle is now translated into
Python's Decimal in 0.6.x, was 'float'
On Dec 7, 6:06 pm, Michael Bayer mike...@zzzcomputing.com wrote:
I hadn't planned any future 0.5 releases, 0.7 is almost ready for betas.
What are the incompatibilities you have with 0.6 ?
Another difference to 0.5.x is that rolling back a fresh engine (or an
engine that has been rolled back)
Hi Michael,
thanks for all your help and support. The Decimal problem is indeed
solved (the comma was the actual problem, not the fact that a numeric
is returned as Decimal). The other problem with rolling back a fresh
engine still persists, I've reopened ticket
Hi Michael,
thanks for your help.
Since some of my engines are not bound to mappers I've tried the
approach suggested in your previous post to subclass Session so that
'get_bind' would accept an additional 'engine' argument. This works
fine with Session.execute() which passes **kw down to the
Hi everybody,
we have the problem that transactions embedded in
'with Session.begin()'
are not committing statements made in raw connections. However
'with engine.begin()' (in 0.5.8)
works fine.
The reason we need to use Session.begin() is that we want to cover
transactions
Hi,
this might be another small bug in SA. It shows up when an Sqlite db
is composed of multiple sub-DBs via the 'attach' statement. This is
useful for mimicking schemata and allows tables to be addressed like
schema.table (using common dot-syntax).
To make the following work run this statement
://hg.sqlalchemy.org/sqlalchemy/archive/default.tar.gz
On Jul 7, 2010, at 10:49 AM, Ralph Heinkel wrote:
oh, I'm sorry, but better now than later ;-) Strange that nobody got
hit by that bug (or the side effects were not as tremendous as in my
case and so they were silently going through with no harm
Hi,
sorry for the late reply. I've now made some measurements, and
repeated those two a couple times to avoid caching effects. I've
reduced it to the innermost sql statement. Here they are:
SELECT entrypoint_id, ...20 about fields ..., ROW_NUMBER() OVER
(ORDER BY creationdate DESC, entrypoint_id
Hi,
is SA 0.6 this problem did not occur. The sample code to demonstrate
the problem is taken from
http://www.sqlalchemy.org/docs/mappers.html#many-to-many
and repeated here for completeness. First let's setup a sample db (all
done in sqlite in my case):
class Parent(object):
def
oh, I'm sorry, but better now than later ;-) Strange that nobody got
hit by that bug (or the side effects were not as tremendous as in my
case and so they were silently going through with no harm ...)
Thanks anyway for looking at this and fixing the problem.
Ciao ciao
Ralph
On Jul 7, 4:08 pm,
On Jun 23, 5:29 pm, Ian Kelly ian.g.ke...@gmail.com wrote:
On Wed, Jun 23, 2010 at 1:50 AM, Ralph Heinkel ralph.hein...@web.de wrote:
Hi,
we are about upgrading our sqlalchemy library from 0.4.8 to something newer
and during this process we have detected that the LIMIT/OFFSET support
Hi Michael,
We have also tried the /*+ FIRST_ROWS(N) */ optimization hint, it
only gave a 25% speed improvement, but the result was still 5 or 7
times slower than the ROW_NUMBER() OVER approach.
I'll provide benchmark details on Monday, also details about table
(actually a view) layout,
Hi,
we are about upgrading our sqlalchemy library from 0.4.8 to something
newer and during this process we have detected that the LIMIT/OFFSET
support for oracle has been changed, from using “ROW NUMBER OVER...”
to a wrapped subquery approach in conjunction with ROWNUM as described
in
24 matches
Mail list logo
