Along the same lines, is there something we can do about nvl()
(oracle) versus coalesce() (ansi)?
They aren't exactly the same, unfortunately (nvl takes exactly 2
arguments, no more), so maybe there is nothing 'official' you can do,
but can you help me work it out for my project?
I assume it is
On Tue, Mar 30, 2010 at 19:32, Michael Bayer mike...@zzzcomputing.com wrote:
Bo Shi wrote:
pep 249 specifies list of tuples for fetchmany() and fetchall()
Hrm, pep-249 seems to only specify sequence and sequence of
sequences for the fetch*() functions, specifying list of tuples only
as one
Kent wrote:
Along the same lines, is there something we can do about nvl()
(oracle) versus coalesce() (ansi)?
They aren't exactly the same, unfortunately (nvl takes exactly 2
arguments, no more), so maybe there is nothing 'official' you can do,
but can you help me work it out for my project?
Thanks very much.
On 4/2/2010 5:41 PM, Michael Bayer wrote:
Kent wrote:
Along the same lines, is there something we can do about nvl()
(oracle) versus coalesce() (ansi)?
They aren't exactly the same, unfortunately (nvl takes exactly 2
arguments, no more), so maybe there is nothing
As an aside, more recent Oracles support ansi coalesce,
so it is probably more appropriate to only use nvl() for older, non-ansi
Oracle versions, but if this is only for illustration then that is not a
big deal (unless you don't want people writing to you saying coalesce
does support more than
Kent Bower wrote:
As an aside, more recent Oracles support ansi coalesce,
so it is probably more appropriate to only use nvl() for older, non-ansi
Oracle versions, but if this is only for illustration then that is not a
big deal (unless you don't want people writing to you saying coalesce
On Fri, Apr 2, 2010 at 3:41 PM, Michael Bayer mike...@zzzcomputing.comwrote:
Kent wrote:
Along the same lines, is there something we can do about nvl()
(oracle) versus coalesce() (ansi)?
They aren't exactly the same, unfortunately (nvl takes exactly 2
arguments, no more), so maybe
Just to be inconsistent, with one argument, databases handle this
differently:
postgres:
# select coalesce(0);
coalesce
--
0
(1 row)
Oracle 10g:
select coalesce(0) from dual
*
ERROR at line 1:
ORA-00938: not enough arguments for function
On Apr 2, 7:08 pm, Ian Kelly
Michael Bayer wrote:
check out r0ddd638f1d90 in mercurial. I've added the function from the
example below, plus support for in_op(), to the attribute_shard example.
The old ClauseVisitor method is removed and replaced with this more robust
method.
Very nice! Thanks, Michael.
/George
--
On Apr 2, 4:43 pm, George V. Reilly george.v.rei...@gmail.com
wrote:
Michael Bayer wrote:
check out r0ddd638f1d90 in mercurial. I've added the function from the
example below, plus support for in_op(), to the attribute_shard example.
The old ClauseVisitor method is removed and replaced
By the way,
Unless a ClauseList is subscriptable in 0.6, I had problems the way
it was.
Here is what I did:
@compiles(coalesce, 'oracle')
def compile(element, compiler, **kw):
sql = nvl(%s)
clauses = map(compiler.process, element.clauses)
for i in xrange(len(clauses) - 2):
After doing more reading, this only relates to multiple class
inheritance, which is useful anytime you want two or more classes to
relate to the same record return from the database, is that an
accurate summary?
I'm trying to get of real-life feel for which situations would
benefit from multiple
I was able to come up with a work-around, since this is part of a
report, I was able to format the dates as strings
the way I was planning to do in python anyways:
qry=session.query(Task,
func.cat(func.to_char(TaskHistory.updated,'MM/DD/YY HH:MI am')))
This works well for my needs (cat()
People can use string-based primaryjoin parameter to define the
sqlalchemy.orm.relation instance if people use declarative base
class. But the __table__ attribute is not available. Look at this
example.
Chassis and Blade are sub-class of System. The sysid property
shares the same name in parent
George V. Reilly wrote:
I really don't like the
isinstance(other_side,
sqlalchemy.sql.expression._BindParamClause))
in the middle of _check_side. Is there a cleaner way to do this?
I found that a combination of
* the above _check_side and two-sided visit_binary
* doing a better job of
Michael Mileusnich wrote:
Hello,
I know there is documentation on this but I am still fuzzy on certain
practices when using the session. In my application I have a function
that
returns a new non scoped session. In one method (method a) I get object o
from this session. I call another
Kent wrote:
After doing more reading, this only relates to multiple class
inheritance, which is useful anytime you want two or more classes to
relate to the same record return from the database, is that an
accurate summary?
I wouldn't say its accurate. SQLA doesn't support any pattern of
Jack wrote:
People can use string-based primaryjoin parameter to define the
sqlalchemy.orm.relation instance if people use declarative base
class. But the __table__ attribute is not available. Look at this
example.
its a limited subset of behaviors which are allowed within the evaluated
Michael Bayer wrote:
George V. Reilly wrote:
I really don't like the
isinstance(other_side,
sqlalchemy.sql.expression._BindParamClause))
in the middle of _check_side. Is there a cleaner way to do this?
I found that a combination of
* the above _check_side and two-sided visit_binary
*
Michael Bayer wrote:
Bo Shi wrote:
pep 249 specifies list of tuples for fetchmany() and fetchall()
Hrm, pep-249 seems to only specify sequence and sequence of
sequences for the fetch*() functions, specifying list of tuples only
as one possible example. Perhaps the C implementation of
Awesome! Thanks!
We work with large amounts of time series data so we have high hopes
for the c extension.
Bo
On Fri, Apr 2, 2010 at 2:38 PM, Michael Bayer mike...@zzzcomputing.com wrote:
Michael Bayer wrote:
Bo Shi wrote:
pep 249 specifies list of tuples for fetchmany() and fetchall()
Hrm, some different errors pop up. I'll move the dialog to the ticket
in question.
http://www.sqlalchemy.org/trac/ticket/1757
On Fri, Apr 2, 2010 at 2:40 PM, Bo Shi bs1...@gmail.com wrote:
Awesome! Thanks!
We work with large amounts of time series data so we have high hopes
for the c
Any chance you plan to make func.now consider oracle and
use_ansi=False (and return sysdate)?
On Feb 3, 4:44 pm, Michael Bayer mike...@zzzcomputing.com wrote:
Kent wrote:
Any chance SQLAlchemy has a mechanism to switch to or fromsysdatevs.
current_datebased on the database dialect (and
Kent wrote:
Any chance you plan to make func.now consider oracle and
use_ansi=False (and return sysdate)?
the use_ansi flag should be removed as far as public API since we can
detect server version now. we can also make now() return sysdate()
unconditionally on oracle, you should give us a
24 matches
Mail list logo
