[sqlalchemy] Python 3.4 Enum type
Since Python 3.4 is adding support for enums to the standard library, I wrote a TypeDecorator for it: import sqlalchemy.types as types class PythonEnum(types.TypeDecorator): impl = types.Enum def __init__(self, enum_class, **kw): super().__init__(*(m.name for m in enum_class), **kw) self._enum_class = enum_class def process_bind_param(self, value, dialect): return value.name def process_result_value(self, value, dialect): return self._enum_class[value] @property def python_type(self): return self._enum_class Comments welcome. Is this something that should be added to sqlalchemy? -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Tea Rota
On Thu, Jan 12, 2012 at 3:14 PM, Calum MacLeod pan...@sky.com wrote: if date not in duties: duty = Duty(date=date) duties[date] = duty if name not in volunteers: volunteer = Volunteer(fore=fore, surn=surn, name=name) volunteers[name] = volunteer volunteer.duties.append(duty) If the date or the volunteer are already in the respective dicts, you never assign the 'duty' or 'volunteer' variable. Thus it would retain its value from the last iteration. This is probably why you seem to be missing volunteers -- some of your dict entries are getting clobbered with the wrong volunteers. Cheers, Ian -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Oracle Connection Oddities
On Thu, Jul 14, 2011 at 12:53 PM, Burhan burhan.kha...@gmail.com wrote: I am not sure what version of cx_Oracle it is - it was downloaded as a Windows binary - the latest version is 5.1 on the cx_Oracle download page. import cx_Oracle print cx_Oracle.version -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] group by and Oracle
On Fri, Dec 3, 2010 at 4:08 AM, jo jose.soa...@sferacarta.com wrote:
Hi all,
I'm trying to write a GROUP BY query grouped by a function (to_char) using a
variable format, which could be 'yy' or ''
as in:
sql=session.query(
func.to_char(Prestazione.c.data,format),
func.sum(Prestazione.c.quantita).label('quantita'),
func.sum(Prestazione.c.importo).label('importo')
)
sql=sql.filter(Verifica.c.codice == Tariffa.c.codice)
sql=sql.filter(Prestazione.c.id_tariffa == Tariffa.c.id)
sql=sql.group_by(Verifica.c.codice, func.to_char(Prestazione.c.data,format))
Have you tried using the same func result in both places, i.e.:
to_char = func.to_char(Prestazione.c.data,format)
sql=session.query(
to_char,
func.sum(Prestazione.c.quantita).label('quantita'),
func.sum(Prestazione.c.importo).label('importo')
)
sql=sql.filter(Verifica.c.codice == Tariffa.c.codice)
sql=sql.filter(Prestazione.c.id_tariffa == Tariffa.c.id)
sql=sql.group_by(Verifica.c.codice, to_char)
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] new LIMIT/OFFSET Support for oracle - huge speed penalty
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 for oracle has been changed, from using “ROW NUMBER OVER...” to a wrapped subquery approach in conjunction with ROWNUM as described in http://www.sqlalchemy.org/docs/reference/dialects/oracle.html#limit-offset-support Unfortunately this approch is about 10 times slower for large tables which is mainly related to the fact that the innermost subquery has to sort the entire table with a plain 'order by'. Interestingly the ROW_NUMBER() OVER (ORDER BY some db fields) is so much more efficient than the normal order by approach. Do you have benchmarks to back that up? In Django, we switched from using row_number to rownum after a contributor convinced me that rownum was faster. See: http://code.djangoproject.com/ticket/9136 Thanks, Ian -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Re: use_ansi oracle sysdate vs. current_date
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 there is nothing 'official' you can do, but can you help me work it out for my project? I assume it is very similar to what you helped me out with above...something like this: from sqlalchemy.sql.expression import ColumnElement from sqlalchemy.ext.compiler import compiles from sqlalchemy.types import DateTime, Date class current_date(ColumnElement): type = Date() @compiles(current_date) def _compiler_dispatch(element, compiler, **kw): if compiler.dialect.name == 'oracle': if compiler.dialect.use_ansi: return trunc(current_date) else: return trunc(sysdate) else: # assume postgres return current_date But the main difference is it takes arguments. Is there a clever way to return the appropriate function, something like this: def if compiler.dialect.name == 'oracle': return func.nvl else: # assume postgres return func.coalesce I will add this to the docs: from sqlalchemy import * from sqlalchemy.ext.compiler import compiles from sqlalchemy.sql.expression import FunctionElement class coalesce(FunctionElement): name = 'coalesce' @compiles(coalesce) def compile(element, compiler, **kw): return coalesce(%s) % compiler.process(element.clauses) @compiles(coalesce, 'oracle') def compile(element, compiler, **kw): if len(element.clauses) 2: raise TypeError(coalesce only supports two arguments on Oracle) return nvl(%s) % compiler.process(element.clauses) print coalesce(5, 6) from sqlalchemy.dialects import oracle print coalesce(5, 6).compile(dialect=oracle.dialect()) Might this work as a more complete solution for Oracle? @compiles(coalesce, 'oracle') def compile(element, compiler, **kw): sql = nvl(%s) for i in xrange(len(element.clauses) - 2): sql %= %s, nvl(%%s) % compiler.process(element.clauses[i:i+1]) return sql % compiler.process(element.clauses[-2:]) Ian -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Oracle timestamp and postgres datetime compatibility
On Wed, Dec 2, 2009 at 3:25 PM, Michael Bayer mike...@zzzcomputing.com wrote: from the article: Beware while the TO_CHAR function works with both datatypes, the TRUNC function will not work with a datatype of TIMESTAMP. This is a clear indication that the use of TIMESTAMP datatype should explicitly be used for date and times where a difference in time is of utmost importance, such that Oracle won't even let you compare like values. this suggests to me that DATE is more of a general purpose date/time type whereas TIMESTAMP is specifically when you need granularity to compare the ordering of events down to the millisecond, with some loss in simplicity . This was fixed in version 9.2.0.3.0. Using that release or later, TRUNC works just fine with TIMESTAMP. See the thread at http://forums.oracle.com/forums/thread.jspa?threadID=372457 I should stress that I don't think using DATE is a problem so long as there's a way to get TIMESTAMP instead. Especially if the goal is to support Oracle 8i, where TIMESTAMP doesn't even exist. Ian -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: #446: Two deletions cascading to the same object can result in an error
Finally, note that I'm _not_ asking for sqlalchemy to maintain the collections for me. All I'm asking is for the cascade code not to attempt to delete objects that have already been deleted and flushed, or at least to safely handle the exception it raises when it does. OK, what behavior are you looking for ? it raises an exception right now. whats unsafe about it ? Well, it interrupts the cascading and leaves session.deleted in an inconsistent state where not all of the object's dependents may be included. I was under the assumption that this meant those dependents wouldn't be deleted, which would be a nightmare for trying to handle the exception. But it seems I was mistaken about that -- the flush finds and deletes the remaining dependents anyway. I could argue that leaving session.deleted in an inconsistent state is still a bad thing, but it's not nearly as severe as I had thought. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
