[sqlalchemy] some error around trunk
seems something about .type vs .type_ or similar:
Traceback (most recent call last):
File tests/convertertest.py, line 152, in
test4_balance_trans_via_prev_balance_date_subselect
trans.c.date func.coalesce( sprev,0 )
File sqlalchemy/sql/expression.py, line 777, in __call__
return func(*c, **o)
File sqlalchemy/sql/functions.py, line 12, in __call__
return type.__call__(self, *args, **kwargs)
File sqlalchemy/sql/functions.py, line 35, in __init__
kwargs.setdefault('type_', _type_from_args(args))
File sqlalchemy/sql/functions.py, line 75, in _type_from_args
if not isinstance(a.type, sqltypes.NullType):
AttributeError: 'Select' object has no attribute 'type'
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: some error around trunk
seems like you might need an as_scalar() on the select object.
otherwise send an example.
On Dec 15, 2007, at 10:06 AM, svilen wrote:
seems something about .type vs .type_ or similar:
Traceback (most recent call last):
File tests/convertertest.py, line 152, in
test4_balance_trans_via_prev_balance_date_subselect
trans.c.date func.coalesce( sprev,0 )
File sqlalchemy/sql/expression.py, line 777, in __call__
return func(*c, **o)
File sqlalchemy/sql/functions.py, line 12, in __call__
return type.__call__(self, *args, **kwargs)
File sqlalchemy/sql/functions.py, line 35, in __init__
kwargs.setdefault('type_', _type_from_args(args))
File sqlalchemy/sql/functions.py, line 75, in _type_from_args
if not isinstance(a.type, sqltypes.NullType):
AttributeError: 'Select' object has no attribute 'type'
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Sessions and threads, find in one thread, use in another
On Dec 13, 2007 12:29 PM, Allen Bierbaum [EMAIL PROTECTED] wrote: On Dec 13, 2007 10:47 AM, Michael Bayer [EMAIL PROTECTED] wrote: On Dec 13, 2007, at 9:55 AM, Allen Bierbaum wrote: In my current application I am running a rather expensive query in a background thread, but then I need to use the results in the foreground thread. The object I find has a great deal of lazy evaluated properties that link it to several other mapped objects. As it stands now, the application is only following the lazy properties when it uses the object in the primary thread. The has multiple engines connected to multiple databases. I have a separate session for each database for each thread. (Note: right now I am doing this manually but I am debating whether I should be using something like SessionContext.) What I am worried about is that by querying the initial parent object in the background thread and then using it's lazy props in the foreground thread, I think SA is probably using the background session to evaluate these links. Is there a recommended way to deal with a situation like this? In other words, what is the recommended practice for moving, reusing objects from a session across multiple threads. Is there some way to remap the object and attach it to the foreground session? theres two general options here. the most appropriate way to move the object between sessions is to use session.merge(). this will create a copy of the object in the target session, which is returned, leaving the old one unchanged, so that it can additionally be merged elsewhere. as of version 0.4.1 we added a flag to merge called dont_load which prevents merge() from reloading the instance from the database upon merge (the classical behavior of this method is that it loads the current data from the database which is merged with the given data). so setting dont_load=True will prevent these loads from happening. we also have some fairly important fixes to dont_load=True in the current trunk which will be out in version 0.4.2, so if you are getting into heavy merge() usage and you need to use the dont_load flag (which is strictly for performance reasons), you might want to go on trunk for awhile. The other option here is to move the object completely from the background to the foreground session. to do this, you would expunge() it from the background session, and then update() it into the target session. this is a simpler operation than merge since nothing is being copied. but youd want to ensure the objects youre moving werent part of some larger collection thats still sitting in the background session. I think I am going to use this second method because I don't want to force a database reload during the merge. Instead I want to use the detached instance for a while. My foreground thread can get by using the loaded version of a couple of the fields of the object in the detached state. Then if/when the code needs to see additional data bout the record (through relationship mappings), I will use update to attach to the foreground session. The one question I have here though is, how can I make the update() call that reattaches it to the foreground session automatically reload the entire record from the database (ie. ignore any local modifications)? Do I have to call update() followed by refresh()? Thanks, Allen --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Matching a DateTime-field
Can't you use a BETWEEN or = and with two dates? If your date column is indexed, as it should be if you're using it frequently in where clauses, the overhead of DATE_FORMAT decreases substantially. On Dec 12, 2007 3:43 PM, Adam B [EMAIL PROTECTED] wrote: On Dec 11, 10:55 am, King Simon-NFHD78 [EMAIL PROTECTED] wrote: It may not matter to you, but I wouldn't have thought this would be a very efficient query, because the database is going to have to call the DATE_FORMAT function twice for every row in your table. I would have thought a more efficient version would be one that asks for all rows between the first of one month and the first of another month (especially if the date column is indexed). Something like: from datetime import date session.query(List).filter( and_(List.expire = date(2007, 12, 1), List.expire date(2008, 1, 1)) ).all() Adding one month to a date is pretty easy, but if you wanted to do any more complicated date calculations, the dateutil library is very good: http://labix.org/python-dateutil Ah yes, was so obsessed with the solution. Letting the mysql work is much more efficient. It will matter under heavy load. I will check out dateutil, thanks. br Adam -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Sessions and threads, find in one thread, use in another
On Dec 15, 2007, at 12:04 PM, Allen Bierbaum wrote: The one question I have here though is, how can I make the update() call that reattaches it to the foreground session automatically reload the entire record from the database (ie. ignore any local modifications)? Do I have to call update() followed by refresh()? sure...or expire() might be more efficient depending on specifics. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: another dynamic relations related problem
On Dec 15, 2007, at 9:34 AM, Vladimir Iliev wrote: hi, i hit another dynamic relations related bug. if you remove lazy='dynamic' from items mapping there's no problem. OK, I know what this is and it involves making query translation a little more intelligent. The issue is not really the dynamic, its the eager loads in conjunction with the limit/offset (and the fact that youre joining a select of two tables to one of the sub tables), and its not able to alias properly when it makes its subqueries since its traversing too deeply and breaking up your inner query. ill have this fixed by tomorrow...its ticket #904. As a workaround for now, either turn off the eager loads in the mapper() configurations and just use eagerload() as an option as needed; or use all() on the dynamic relation (which sort of defeats the purpose of a dynamic relation) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Database Referential Integrity Constraints Puzzle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi jerryji, this database is not normalized. you may consider switching to: things(thingid INTEGER, thing_weight etc.) and things_translations(thingid INTEGER, thing_name VARCHAR, language CHAR(5)) jerryji wrote: Dear Kind Soul, I am stuck with the following database referential integrity constraint problem. I have two tables: things(thingid INTEGER, thing_name VARCHAR, language CHAR(5)) and thing_relations(thingid INTEGER, thing_parentid INTEGER) things hosts items in different languages, e.g.: things(1, 'car', 'en_US'); things(1, 'voiture', 'fr_FR'); things(2, 'engine', 'en_US'); things(2, 'moteur', 'fr_FR'); things(3, 'brake', 'en_US'); things(3, 'freins', 'fr_FR'); while thing_relations describes the consists of relationship between things, e.g.: thing_relations(2, 1); thing_relations(3, 1) as engine and brake are parts of a car but since things(thingid) is not unique hence it can't be the primary key in things and can't be the foreign key in thing_relations, how can the referential integrity constraints between thing_relations(thingid) and things(thingid) be described? Or my design is not making sense? Many thanks in advance. Jerry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR2TRNNpwN1sq38njAQLJPgP/diPRHpnH7s/auHx/LTXF5Y2Hx7npdLc/ yLuhvjx6Qatm4eU8sASFLLcTEYv1EZsOMRNVaxBEq7Aq89DeSPGVjIl7iy4egjKv rKIyCA4W5nhB37vFbdjMpd1fOmLiUqdtm/ObvSBxb6x3Hd3JDXYwcr86ve5j0XtT hlMT5X2uG4g= =WTdr -END PGP SIGNATURE- --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: some error around trunk
from sqlalchemy import *
m= MetaData()
trans =Table( 'trans', m, Column( 'date', Date), )
balance=Table( 'balance', m, Column( 'finaldate', Date), )
b = balance.alias('b')
sprev = select( [ func.max( b.c.finaldate)],
b.c.finaldate balance.c.finaldate
)
#correlate is non-generative in 0.3 (ret None) but generative in 0.4
sprev = sprev.correlate( balance) or sprev
r = trans.c.date func.coalesce( sprev,0 )
#, as_scalar=True ) with or without all the same
Michael Bayer wrote:
seems like you might need an as_scalar() on the select object.
otherwise send an example.
On Dec 15, 2007, at 10:06 AM, svilen wrote:
seems something about .type vs .type_ or similar:
Traceback (most recent call last):
File tests/convertertest.py, line 152, in
test4_balance_trans_via_prev_balance_date_subselect
trans.c.date func.coalesce( sprev,0 )
File sqlalchemy/sql/expression.py, line 777, in __call__
return func(*c, **o)
File sqlalchemy/sql/functions.py, line 12, in __call__
return type.__call__(self, *args, **kwargs)
File sqlalchemy/sql/functions.py, line 35, in __init__
kwargs.setdefault('type_', _type_from_args(args))
File sqlalchemy/sql/functions.py, line 75, in _type_from_args
if not isinstance(a.type, sqltypes.NullType):
AttributeError: 'Select' object has no attribute 'type'
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
