Re: [sqlalchemy] alembic questions/comments
On 30/05/2013 18:06, Colleen Ross wrote: What would be great would be to have .sql files and .sqli (mako templates with some context provided by the env.py) in addition to .py files. How hard could that be? ;-) UHHH Alembic *doesn't* support this?! Are you kidding me? Fuckit, I'm sticking to sqlalchemy-migrate. Good luck to you... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sqlalchemy] Recipe for text search across multiple fields
Hi,
Often you want to offer the user a text box which will search through
multiple fields. If the user is looking at the list of orders, they want a
search box that will search: order id, customer name, product names, etc.
I'm trying to put together a recipe for this, although it's becoming more
complicated than I planned.
The recipe will take three inputs: mapped class, list of fields, search
term. The list of fields will be like ['id', 'customer.name',
'products.name'] - where there is a dot in the field name, that indicates
the search should walk a relation. For starters the matching will be an
ilike with % characters put around the search term.
This is what I came up with so far:
def text_search(cls, fields, search):
queries = []
for field in fields:
query = cls.query.order_by(None)
parts = field.split('.')
cur_cls = cls
for part in parts[:-1]:
attr = getattr(cur_cls, part)
cur_cls = attr.property.mapper.class_
query = query.outerjoin(attr)
queries.append(query.filter(getattr(cur_cls,
parts[-1]).ilike('%'+search+'%')))
return queries[0].union(*queries[1:])
The problem is I'm getting PostgreSQL syntax errors, because some order_by
clauses are still appearing in the queries, which don't play nice with the
union. Any suggestions for fixing this would be welcome!
Once that's fixed, and with a few more refinements, I think this would be a
very handy recipe to keep around, or even put in the SQLAlchemy core.
Paul
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sqlalchemy] How to update PickleType column using DBSession.execute()
How to update PickleType column using DBSession.execute()
class MyTable(DeclarativeBase):
__tablename__ = 'mytable'
context = Column(PickleType)
*Attempt 1
*
context = {k1:{n1:bbla}, k2:{n2:bbla}}
context = pickle.dumps(context)
DBSession.execute(update mytable set context='%s' where t_id=%s;
%(context, id))
DBSession.execute(commit;)
*Error
*
ProgrammingError: (ProgrammingError) (1064, You have an error in your SQL
syntax; check the manual that corresponds to your MySQL server version for
the right syntax to use near 'shortD'\np1\nS'bla bla
bla%s'\np2\nsS'child'\np3\n(dp4\nS'im' at line 1) uupdate mytable set
context='(dp0\nS'shortD'\np1\nS'blabla
%%s'\np2\nsS'child'\np3\n(dp4\nS'import_disk'\np5\n(dp6\nS't_id'\np7\nL11092L\nsssS'shortDP'\np8\n(V2\np9\ntp10\nsS'description'\np11\ng2\nsS'descParams'\np12\n(V2\np13\ntp14\ns.'
where t_id=11091;
*Attempt 2
*
context = {k1:{n1:bbla}, k2:{n2:bbla}}
context = re.escape(str(context))
context = pickle.dumps(context)
DBSession.execute(update mytable set context='%s' where t_id=%s;
%(context, id))
DBSession.execute(commit;)
*
Error
*
ProgrammingError: (ProgrammingError) (1064, You have an error in your SQL
syntax; check the manual that corresponds to your MySQL server version for
the right syntax to use near 'shortDesc': 'bla bla
bla %s', 'child_' at line 1) u'update mytable
set context=\'S{\'shortD\': \'bla bla
bla %%s\', \'child_s\':
{\'import_disk\':
{\'t_id\': 11145L}},
\'shortDP\': (u\'2\',),
\'description\': \'bla Virtual bla
%%s\', \'descP\':
(u\'2\',)}\np0\n.\' where t_id=11144;'
*Note:
=*
* I want to use only DBSession.execute().
* I know that following code will works, But i want to use
DBSession.execute().
DBSession.query(MyTable).filter(MyTable.t_id==id).update(values=dict(context=context))
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] [Q][0.7.9] How to issue apply_labels() on an ORM query?
Glad I could help, but I don't understand what is going on. Neither ticket description nor the patch itself helped me. Sorry. What is select_from() good for when it generates a cartesian query? What MIGHT help ME (a lot infact) is a couple of DOs and DONTs examples in one place for all these three constructs OR A 'highlevel user-friendly step-by-step description' about what each construct does, so that I can see where they differ. Anyway, keep the excellent work! Ladislav Lenart On 31.5.2013 01:12, Michael Bayer wrote: this is very helpful because you are here running into an older feature that I think is not very applicable to modern usage, not to mention not terrifically documented, so I've added http://www.sqlalchemy.org/trac/attachment/ticket/2736/ to address changing the role of select_from() to be more what it says, and to offload a particular magic aspect of it into a new method called select_entity_from(). if you look at the docstrings added to the patch there, you may get a sense for what's been going on. I'll probably commit this soon and those docs will be up on the site. There will be an upgrade path for users in this case. On May 30, 2013, at 1:10 PM, Ladislav Lenart lenart...@volny.cz wrote: Hello. Sorry for the long delay. I finally had enough time to produce a minimal self-contained regression. The attached file produces the following SQL: WITH RECURSIVE q_cte(partner_id, max_depth) AS ( SELECT partner.id AS partner_id, 1 AS max_depth FROM partner WHERE partner.sponsor_id IS NULL UNION ALL SELECT partner_alias.id AS partner_id, max_depth + 1 AS max_depth FROM partner AS partner_alias, q_cte AS q_cte_alias WHERE partner_alias.sponsor_id = q_cte_alias.partner_id ) SELECT q_cte.partner_id AS q_cte_partner_id, -- suspicious partner.sponsor_id AS partner_sponsor_id FROM q_cte JOIN partner ON q_cte.partner_id = q_cte.partner_id -- BUG I would expect this (q_cte part is correct): WITH RECURSIVE q_cte(partner_id, max_depth) AS ( ... ) SELECT partner.id AS partner_id, partner.sponsor_id AS partner_sponsor_id FROM q_cte JOIN partner ON q_cte.partner_id = partner.id The bug is somehow related to the use of select_from(). Hope this helps, Ladislav Lenart On 10.5.2013 22:04, Michael Bayer wrote: On May 10, 2013, at 3:03 PM, Ladislav Lenart lenart...@volny.cz wrote: Hello. My main concern was that the query creates a cartesian product and I thought the warning might have something to do with it. It haven't. The problem is related to the use of select_from(): q = session.query(cls, PersonalContact).select_from(q_cte_union) q = q.join(cls, cls.id == q_cte_union.c.partner_id) This part renders the following SQL: SELECT * FROM q_cte JOIN partner ON q_cte.partner_id = q_cte.partner_id As you can see, the JOIN condition is wrong though I have no idea why. The following works, however: q = session.query(cls) q = q.add_entity(PersonalContact) q = q.join(q_cte_union, cls.id == q_cte_union.c.partner_id) Is my usage of select_from() bad for some reason? Do you know what's going on? I can provide you a fully runnable test case if you still need it (on Monday). Note also that I use SA 0.7.9. Is this fixed in later versions? I've no idea why you're getting it without more context - if everything is generated from a query(), typically the labels are already applied, with the exception of some operations such as subquery() (maybe cte? not sure, I'd need to try it, hence an already existing example saves me lots of time tinkering around trying to guess what you're doing). Things have been improved in 0.8 regarding same-named columns but that only applies when the labels are already present. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out. select_from_bug.py -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] [Q][0.7.9] How to issue apply_labels() on an ORM query?
Hello. I've read the patch and the new documentation and i've learned about the existence of select_entity_from(). I was trying to say that the new documentation does not help me to understand the meaning / preferred usage of these constructs (i.e. select_from, select_entity_from and aliased). I simply don't understand when should I use which and why. I have already solved my original problem by replacing select_from() with add_entity() and join(). Take a look at older posts in this thread for more details if you're interested, though the original query is a bit more involved than the supplied regression. Ladislav Lenart On 31.5.2013 12:06, Andrija Zarić wrote: On Friday, May 31, 2013 11:46:46 AM UTC+2, Ladislav Lenart wrote: Glad I could help, but I don't understand what is going on. Neither ticket description nor the patch itself helped me. Sorry. What is select_from() good for when it generates a cartesian query? What MIGHT help ME (a lot infact) is a couple of DOs and DONTs examples in one place for all these three constructs OR A 'highlevel user-friendly step-by-step description' about what each construct does, so that I can see where they differ. Hi, Lenart! In the patch you can find doc for the new method Query.select_entity_from. As I read it, it replaces Query.select_from. Have you tried simply replacing old method with the new one (after applying the patch)? a. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] DISTINCT with LIMIT problem
Thanks very much! I got it to work apparently fine using from_self().
I didn't seem to need anything special for eager loads to continue to
function... were you only expecting I'd have troubles with eager loads
if I used subquery()?
On 5/30/2013 6:29 PM, Michael Bayer wrote:
On May 30, 2013, at 6:06 PM, Kent jkentbo...@gmail.com wrote:
Thank you, I'll try that, but quick concern: I specifically skipped trying to use
.subquery() because the docs say Eager JOIN generation within the query is
disabled.
Doesn't that mean I won't get my joinedload() results from the inner query?
Or does that refer to the outer query having eager join disabled?
if you want to eager load also from that subquery, you need to sitck it into an
aliased:
MySubqClass = aliased(MyClass, subq)
query(x, MySubqClass).options(joinedload(MySubqClass.foobar))
On 5/30/2013 5:54 PM, Michael Bayer wrote:
On May 30, 2013, at 5:19 PM, Kent jkentbo...@gmail.com
mailto:jkentbo...@gmail.com wrote:
Solution A:
Group by all columns (yielding the same effect as distinct), but
which makes the window analytical function process *after* the group
by and yields the correct count (17 instead of 72):
are all those columns indexed? even if they are, crappy query...
OR Solution B:
Put the count(*) over () in an outer select, like this:
select count(*) over () as recordcount, anon.*
from (
select distinct tablea.colx, tableb.coly
from tablea, tableb
) as anon
limit 100
this is very much how SQLAlchemy wants you to do it.
Either solution yields the correct answer I believe, but I'm having
difficulty translating the SQL that I know will work into sqlalchemy land.
For Solution B, I don't know how to wrap my query in an outer select
(similar to the LIMIT implementation for Oracle) in a way that will
still allow sqlalchemy to extract rows into instances:
from_self() can do this (probably use add_column() for the window
function), or subquery() should work very well. subq = q.subquery(); q
= query(func.count('*').over().label(..), subq); .
send me a quick example if that's not working and I'll work out the query.
--
You received this message because you are subscribed to a topic in the
Google Groups sqlalchemy group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/sqlalchemy/_U28GXXR6sg/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] How to update PickleType column using DBSession.execute()
On Fri, May 31, 2013 at 10:28 AM, sajuptpm sajup...@gmail.com wrote:
How to update PickleType column using DBSession.execute()
class MyTable(DeclarativeBase):
__tablename__ = 'mytable'
context = Column(PickleType)
Attempt 1
context = {k1:{n1:bbla}, k2:{n2:bbla}}
context = pickle.dumps(context)
DBSession.execute(update mytable set context='%s' where t_id=%s;
%(context, id))
DBSession.execute(commit;)
Error
ProgrammingError: (ProgrammingError) (1064, You have an error in your SQL
syntax; check the manual that corresponds to your MySQL server version for
the right syntax to use near 'shortD'\np1\nS'bla bla
bla%s'\np2\nsS'child'\np3\n(dp4\nS'im' at line 1) uupdate mytable set
context='(dp0\nS'shortD'\np1\nS'blabla
%%s'\np2\nsS'child'\np3\n(dp4\nS'import_disk'\np5\n(dp6\nS't_id'\np7\nL11092L\nsssS'shortDP'\np8\n(V2\np9\ntp10\nsS'description'\np11\ng2\nsS'descParams'\np12\n(V2\np13\ntp14\ns.'
where t_id=11091;
Attempt 2
context = {k1:{n1:bbla}, k2:{n2:bbla}}
context = re.escape(str(context))
context = pickle.dumps(context)
DBSession.execute(update mytable set context='%s' where t_id=%s;
%(context, id))
DBSession.execute(commit;)
Error
ProgrammingError: (ProgrammingError) (1064, You have an error in your SQL
syntax; check the manual that corresponds to your MySQL server version for
the right syntax to use near 'shortDesc': 'bla bla
bla %s', 'child_' at line 1) u'update mytable
set context=\'S{\'shortD\': \'bla bla
bla %%s\', \'child_s\':
{\'import_disk\': {\'t_id\':
11145L}}, \'shortDP\':
(u\'2\',), \'description\':
\'bla Virtual bla %%s\',
\'descP\': (u\'2\',)}\np0\n.\'
where t_id=11144;'
Note:
=
* I want to use only DBSession.execute().
* I know that following code will works, But i want to use
DBSession.execute().
DBSession.query(MyTable).filter(MyTable.t_id==id).update(values=dict(context=context))
Don't use string interpolation (Python's % operator) with SQL
strings. It means you have to take care of all the quoting yourself,
and potentially open yourself up to SQL injection attacks.
Instead, you should use bind parameters, something like this:
context = {k1:{n1:bbla}, k2:{n2:bbla}}
context = pickle.dumps(context)
DBSession.execute(update mytable set context=:context where
t_id=:id, {'context': context, 'id': id})
See the documentation at:
http://docs.sqlalchemy.org/en/rel_0_8/orm/session.html#sqlalchemy.orm.session.Session.execute
Hope that helps,
Simon
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] DISTINCT with LIMIT problem
Am 30.05.2013, 23:19 Uhr, schrieb Kent jkentbo...@gmail.com: For example, a query may look like this: select distinct count(*) over () as recordcount, tablea.colx, tableb.coly from tablea, tableb where limit 100 This doesn't *quite* work because the analytical window function count(*) over() is applied *before* the distinct, so the count returns the wrong number (a Cartesian effect, returning 72 instead of 17, in this example). Why are you generating Cartesian products? DISTINCT is designed to work on denormalised result sets, ie. those which can contain duplicates. Can't you avoid this with a join between your tables? Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] DISTINCT with LIMIT problem
I allow the user to join with other tables for the purpose of filtering
(even though the joined tables won't be selected). Cartesian is
probably the wrong term for the effect, but in the end, I get duplicate
rows. I could get rid of the need for distinct by extensively using
EXISTS clauses instead of joins; this is true.
But when several tables are chained to together with joins, I expect
using EXISTS to become less manageable and to perform poorer. (I could
be wrong on both accounts.)
For example, our interface may allow the query of Employee records. But
the user might join with the EmailAddress table to strictly filter results.
Employee records:
idname
1 kent
2 charlie
EmailAddress records:
empid address
===
1k...@mymail.goo
1k...@mymail.goo
1k...@gmail.de
2char...@gmail.de
session.query(Employee).join(EmailAddress).filter(EmailAddress.contains('@'))
Remember, we are only selecting emp.id, emp.name (but joining with
another table).
So without DISTINCT:
idname
1 kent
1 kent
1 kent
2 charlie
With DISTINCT:
idname
1 kent
2 charlie
Like I say, using EXISTS would remove the need for DISTINCT, but I
haven't gone down that path...
On 5/31/2013 8:41 AM, Charlie Clark wrote:
Am 30.05.2013, 23:19 Uhr, schrieb Kent jkentbo...@gmail.com:
For example, a query may look like this:
select distinct
count(*) over () as recordcount, tablea.colx, tableb.coly
from tablea, tableb
where
limit 100
This doesn't *quite* work because the analytical window function count(*)
over() is applied *before* the distinct, so the count returns the wrong
number (a Cartesian effect, returning 72 instead of 17, in this example).
Why are you generating Cartesian products? DISTINCT is designed to work
on denormalised result sets, ie. those which can contain duplicates.
Can't you avoid this with a join between your tables?
Charlie
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] [Q][0.7.9] How to issue apply_labels() on an ORM query?
On Friday, May 31, 2013 11:46:46 AM UTC+2, Ladislav Lenart wrote: Glad I could help, but I don't understand what is going on. Neither ticket description nor the patch itself helped me. Sorry. What is select_from() good for when it generates a cartesian query? What MIGHT help ME (a lot infact) is a couple of DOs and DONTs examples in one place for all these three constructs OR A 'highlevel user-friendly step-by-step description' about what each construct does, so that I can see where they differ. Hi, Lenart! In the patch you can find doc for the new method Query.select_entity_from. As I read it, it replaces Query.select_from. Have you tried simply replacing old method with the new one (after applying the patch)? a. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] [Q][0.7.9] How to issue apply_labels() on an ORM query?
On Fri, May 31, 2013 at 12:31 PM, Ladislav Lenart lenart...@volny.czwrote: Hello. I've read the patch and the new documentation and i've learned about the existence of select_entity_from(). I was trying to say that the new documentation does not help me to understand the meaning / preferred usage of these constructs (i.e. select_from, select_entity_from and aliased). I simply don't understand when should I use which and why. I have already solved my original problem by replacing select_from() with add_entity() and join(). Take a look at older posts in this thread for more details if you're interested, though the original query is a bit more involved than the supplied regression. Ladislav Lenart Sorry I rushed with the reply! I haven't carefully read your original post, but concentrated on the patch as I was hoping it was relevant to my issue. More importantly, I was misleading and wrong in trying to 'summarize' the docs, stating there are new and old methods. The examples in the patch say those two cases: select_stmt = select([User]).where(User.id == 7) q = session.query(User).select_entity_from(select_stmt) user_from_select = aliased(User, select_stmt.alias()) should produce similar result, i.e. give you User entity from different mapping then usual; whether select_from() should work as intended - resulting cartesian product in docs example should be 'eliminated' by further join. Cheers, a. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Query and compiled_cache
On Thu, May 30, 2013 at 7:04 PM, Michael Bayer mike...@zzzcomputing.com wrote: The hashing thing really has to start as a core concept first. It's a big job but would be very helpful for caching scenarios and would allow us to build this feature on Query without too much difficulty. The nice thing about unhashable is that simple queries will be hashable, but as soon as complexity increases you'd start seeing unhashables come in, preventing us from caching something that isn't actually easy to cache. AFAIK only py3 has support for making user classes unhashable. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Query and compiled_cache
On Friday, May 31, 2013 10:18:41 AM UTC-4, Klauss wrote: On Thu, May 30, 2013 at 7:04 PM, Michael Bayer mik...@zzzcomputing.comjavascript: wrote: The hashing thing really has to start as a core concept first. It's a big job but would be very helpful for caching scenarios and would allow us to build this feature on Query without too much difficulty. The nice thing about unhashable is that simple queries will be hashable, but as soon as complexity increases you'd start seeing unhashables come in, preventing us from caching something that isn't actually easy to cache. AFAIK only py3 has support for making user classes unhashable. I'm not considering using `__hash__()` for this, I'd rather keep it as a special method for this purpose. But after sleeping on it, I'm still pretty skeptical, because it's actually pretty difficult to determine what parts of a statement will remain constant across backends. If you have a select like, SELECT x + ? FROM q, where ? is a bound parameter, that statement won't run on some backends which don't allow bound parameters in the columns clause. So a select() object select([x + 3]), we would theoretically have to include the number 3 as part of its cache key...but based on where the 3 is present. Similar things happen when you say select().limit(x) - LIMIT can usually be rendered via bound parameter, but not on backends like Sybase or SQL Server where it is rendered in the TOP clause that can't be bound. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] [Q][0.7.9] How to issue apply_labels() on an ORM query?
On Friday, May 31, 2013 6:31:25 AM UTC-4, Ladislav Lenart wrote: Hello. I've read the patch and the new documentation and i've learned about the existence of select_entity_from(). I was trying to say that the new documentation does not help me to understand the meaning / preferred usage of these constructs (i.e. select_from, select_entity_from and aliased). I simply don't understand when should I use which and why. use select_from() as you have been, and you're done. It now does what you expect. A more detailed explanation is here: http://docs.sqlalchemy.org/en/latest/changelog/migration_09.html#query-select-from-no-longer-applies-the-clause-to-corresponding-entities I have already solved my original problem by replacing select_from() with add_entity() and join(). Take a look at older posts in this thread for more details if you're interested, though the original query is a bit more involved than the supplied regression. Ladislav Lenart On 31.5.2013 12:06, Andrija Zarić wrote: On Friday, May 31, 2013 11:46:46 AM UTC+2, Ladislav Lenart wrote: Glad I could help, but I don't understand what is going on. Neither ticket description nor the patch itself helped me. Sorry. What is select_from() good for when it generates a cartesian query? What MIGHT help ME (a lot infact) is a couple of DOs and DONTs examples in one place for all these three constructs OR A 'highlevel user-friendly step-by-step description' about what each construct does, so that I can see where they differ. Hi, Lenart! In the patch you can find doc for the new method Query.select_entity_from. As I read it, it replaces Query.select_from. Have you tried simply replacing old method with the new one (after applying the patch)? a. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Recipe for text search across multiple fields
On May 31, 2013, at 5:06 AM, Paul Johnston paul@gmail.com wrote:
Hi,
Often you want to offer the user a text box which will search through
multiple fields. If the user is looking at the list of orders, they want a
search box that will search: order id, customer name, product names, etc. I'm
trying to put together a recipe for this, although it's becoming more
complicated than I planned.
The recipe will take three inputs: mapped class, list of fields, search term.
The list of fields will be like ['id', 'customer.name', 'products.name'] -
where there is a dot in the field name, that indicates the search should walk
a relation. For starters the matching will be an ilike with % characters put
around the search term.
This is what I came up with so far:
def text_search(cls, fields, search):
queries = []
for field in fields:
query = cls.query.order_by(None)
parts = field.split('.')
cur_cls = cls
for part in parts[:-1]:
attr = getattr(cur_cls, part)
cur_cls = attr.property.mapper.class_
query = query.outerjoin(attr)
queries.append(query.filter(getattr(cur_cls,
parts[-1]).ilike('%'+search+'%')))
return queries[0].union(*queries[1:])
The problem is I'm getting PostgreSQL syntax errors, because some order_by
clauses are still appearing in the queries, which don't play nice with the
union. Any suggestions for fixing this would be welcome!
Once that's fixed, and with a few more refinements, I think this would be a
very handy recipe to keep around, or even put in the SQLAlchemy core.
what's the purpose of cls.query.order_by(None) ? you're not using
mapper.order_by i hope ?
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Query and compiled_cache
On Fri, May 31, 2013 at 11:29 AM, Michael Bayer mike...@zzzcomputing.com wrote: On Friday, May 31, 2013 10:18:41 AM UTC-4, Klauss wrote: On Thu, May 30, 2013 at 7:04 PM, Michael Bayer mik...@zzzcomputing.com wrote: The hashing thing really has to start as a core concept first. It's a big job but would be very helpful for caching scenarios and would allow us to build this feature on Query without too much difficulty. The nice thing about unhashable is that simple queries will be hashable, but as soon as complexity increases you'd start seeing unhashables come in, preventing us from caching something that isn't actually easy to cache. AFAIK only py3 has support for making user classes unhashable. I'm not considering using `__hash__()` for this, I'd rather keep it as a special method for this purpose. But after sleeping on it, I'm still pretty skeptical, because it's actually pretty difficult to determine what parts of a statement will remain constant across backends. It's not necessary to be constant across backends. All of compiled_cache machinery already appends the dialect so only semantically constant would be required. If you have a select like, SELECT x + ? FROM q, where ? is a bound parameter, that statement won't run on some backends which don't allow bound parameters in the columns clause. So a select() object select([x + 3]), we would theoretically have to include the number 3 as part of its cache key...but based on where the 3 is present. Similar things happen when you say select().limit(x) - LIMIT can usually be rendered via bound parameter, but not on backends like Sybase or SQL Server where it is rendered in the TOP clause that can't be bound. So yeah, you don't have to care about that. It's taken care at other levels. Hashing should be concerned with semantics only. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] [Q][0.7.9] How to issue apply_labels() on an ORM query?
Thank you for the excellent description. The replace in bold did the trick for me :-) Ladislav Lenart On 31.5.2013 16:31, Michael Bayer wrote: On Friday, May 31, 2013 6:31:25 AM UTC-4, Ladislav Lenart wrote: Hello. I've read the patch and the new documentation and i've learned about the existence of select_entity_from(). I was trying to say that the new documentation does not help me to understand the meaning / preferred usage of these constructs (i.e. select_from, select_entity_from and aliased). I simply don't understand when should I use which and why. use select_from() as you have been, and you're done. It now does what you expect. A more detailed explanation is here: http://docs.sqlalchemy.org/en/latest/changelog/migration_09.html#query-select-from-no-longer-applies-the-clause-to-corresponding-entities I have already solved my original problem by replacing select_from() with add_entity() and join(). Take a look at older posts in this thread for more details if you're interested, though the original query is a bit more involved than the supplied regression. Ladislav Lenart On 31.5.2013 12:06, Andrija Zarić wrote: On Friday, May 31, 2013 11:46:46 AM UTC+2, Ladislav Lenart wrote: Glad I could help, but I don't understand what is going on. Neither ticket description nor the patch itself helped me. Sorry. What is select_from() good for when it generates a cartesian query? What MIGHT help ME (a lot infact) is a couple of DOs and DONTs examples in one place for all these three constructs OR A 'highlevel user-friendly step-by-step description' about what each construct does, so that I can see where they differ. Hi, Lenart! In the patch you can find doc for the new method Query.select_entity_from. As I read it, it replaces Query.select_from. Have you tried simply replacing old method with the new one (after applying the patch)? a. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Query and compiled_cache
On May 31, 2013, at 10:51 AM, Claudio Freire klaussfre...@gmail.com wrote:
On Fri, May 31, 2013 at 11:29 AM, Michael Bayer
mike...@zzzcomputing.com wrote:
On Friday, May 31, 2013 10:18:41 AM UTC-4, Klauss wrote:
On Thu, May 30, 2013 at 7:04 PM, Michael Bayer mik...@zzzcomputing.com
wrote:
The hashing thing really has to start as a core concept first. It's a
big job but would be very helpful for caching scenarios and would allow us
to build this feature on Query without too much difficulty. The nice thing
about unhashable is that simple queries will be hashable, but as soon as
complexity increases you'd start seeing unhashables come in, preventing us
from caching something that isn't actually easy to cache.
AFAIK only py3 has support for making user classes unhashable.
I'm not considering using `__hash__()` for this, I'd rather keep it as a
special method for this purpose.
But after sleeping on it, I'm still pretty skeptical, because it's actually
pretty difficult to determine what parts of a statement will remain
constant across backends.
It's not necessary to be constant across backends. All of
compiled_cache machinery already appends the dialect so only
semantically constant would be required.
if I have a query:
q = s.query(X).filter_by(foo='bar').limit(3)
say we have it generate a hash:
X._hash = x_hash
X.foo._hash = foo_hash
operator.eq._hash = eq_hash
bindparam('foo')._hash = bp_foo_hash
bindparam('limit')._hash = limit_hash
the hash is: hash(x_hash, foo_hash, eq_hash, bp_foo_hash, limit_hash)
this hash works for backends that can render LIMIT as a bound parameter. It
will *not* work for SQL server which cannot render LIMIT as a bound parameter.
If the hash is determined at the level of Query, we *do not* know whether or
not the backend supports LIMIT as a bound parameter, unless we ask it.
So OK, we make more rules - ask the backend if LIMIT can be hashed as a bound
parameter.
But then what if a particular backend has more restrictive bound parameter
rules than Query is aware of? What if we throw the Firebird backend at it,
and all the sudden Firebird has some quirk where you can't put a bound
parameter inside of a CASE statement inside of the columns clause? How will
Query know that suddenly another deeply embedded bound parameter can no longer
be considered hashable as a bound parameter, and must be hashed as a literal
value ?
The only way that can work generically, is if Query *never* bypasses literals.
it means the above query would have to be hashed like this:
X._hash = x_hash
X.foo._hash = foo_hash
operator.eq._hash = eq_hash
'bar'.hash = bar_hash
3._hash = 3_hash
the hash is: hash(x_hash, foo_hash, eq_hash, bar_hash, 3_hash)
which means the only way you can get parameter hashing is if you write your
Query like this:
q =
s.query(X).filter_by(foo=bindparam('foo')).limit(bindparam('limit')).params(foo='bar',
limit=3)
which means the behavior isn't very transparent at all, and if we are leaning
on the user to explicitly define that things are hashable, we might as well
stick with bake() or something klunky like that which nobody will ever use.
Exposing a confusing and awkward conditional performance API to the userbase is
not good enough to warrant changing the internals. People are confused enough
by yield_per().
If you have a select like, SELECT x + ? FROM q, where ? is a bound
parameter, that statement won't run on some backends which don't allow bound
parameters in the columns clause. So a select() object select([x + 3]),
we would theoretically have to include the number 3 as part of its cache
key...but based on where the 3 is present. Similar things happen when
you say select().limit(x) - LIMIT can usually be rendered via bound
parameter, but not on backends like Sybase or SQL Server where it is
rendered in the TOP clause that can't be bound.
So yeah, you don't have to care about that. It's taken care at other
levels. Hashing should be concerned with semantics only.
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Query and compiled_cache
On Fri, May 31, 2013 at 12:46 PM, Michael Bayer mike...@zzzcomputing.com wrote: this hash works for backends that can render LIMIT as a bound parameter. It will *not* work for SQL server which cannot render LIMIT as a bound parameter. If the hash is determined at the level of Query, we *do not* know whether or not the backend supports LIMIT as a bound parameter, unless we ask it. So OK, we make more rules - ask the backend if LIMIT can be hashed as a bound parameter. But then what if a particular backend has more restrictive bound parameter rules than Query is aware of? What if we throw the Firebird backend at it, and all the sudden Firebird has some quirk where you can't put a bound parameter inside of a CASE statement inside of the columns clause? How will Query know that suddenly another deeply embedded bound parameter can no longer be considered hashable as a bound parameter, and must be hashed as a literal value ? I see. The solution is to create a new object type, QueryKey, that contains both the Query and the Dialect, and builds its hash either by invoking Query.hash(dialect), or by visiting it somehow. The underlying problem is that Query cannot decide the hash by itself. Then it shouldn't try to. It should only support building a hash with respect to a specific dialect. The only thing required of it is that the hash be stable within cacheable queries of that dialect, no need to ponder about hasheability across all dialects. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Query and compiled_cache
On May 31, 2013, at 11:59 AM, Claudio Freire klaussfre...@gmail.com wrote: On Fri, May 31, 2013 at 12:46 PM, Michael Bayer mike...@zzzcomputing.com wrote: this hash works for backends that can render LIMIT as a bound parameter. It will *not* work for SQL server which cannot render LIMIT as a bound parameter. If the hash is determined at the level of Query, we *do not* know whether or not the backend supports LIMIT as a bound parameter, unless we ask it. So OK, we make more rules - ask the backend if LIMIT can be hashed as a bound parameter. But then what if a particular backend has more restrictive bound parameter rules than Query is aware of? What if we throw the Firebird backend at it, and all the sudden Firebird has some quirk where you can't put a bound parameter inside of a CASE statement inside of the columns clause? How will Query know that suddenly another deeply embedded bound parameter can no longer be considered hashable as a bound parameter, and must be hashed as a literal value ? I see. The solution is to create a new object type, QueryKey, that contains both the Query and the Dialect, and builds its hash either by invoking Query.hash(dialect), or by visiting it somehow. The underlying problem is that Query cannot decide the hash by itself. Then it shouldn't try to. It should only support building a hash with respect to a specific dialect. The only thing required of it is that the hash be stable within cacheable queries of that dialect, no need to ponder about hasheability across all dialects. right. which becomes - you have to entirely build out the select() statement *and* and run it through a system that looks very much like the compiler - every time! in order to find edge cases like, we can't use a bound parameter inside of a CASE() inside the columns clause essentially means a process that is very close to the complexity as the full compilation has to proceed. All dialects need to be enhanced in order to support this whole new system, or if we piggyback it onto the existing compilation process, then we're not saving anything at all - and we've already lost the savings of skipping Query._compile_context(). OTOH, if we keep this as bake(), forego Query producing hash keys, and just make it so that bake() can accept a string: q = query(Entity).filter_by(foo=bar).limit(5).bake(my_query) then we can just have Query look up the _compile_context() result for my_query, which takes you right to your dialect-compiled select() constructs which expose which parameters are bound, and then you get all the savings. This is just a few lines different to the existing bake() recipe. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sqlalchemy] Inheritance, and tableless base class with relationship
Hi. I have the following structuring of classes with a base class without a
table.
User(base):
address = relationship('Address', backref=backref(user, uselist=False))
address_id = Column(Integer)
Address(base):
__tablename__ = 'address'
info = Column(String(255))
Info2 = Column(String(255))
Employee(User):
__tablename__ = 'employee'
__mapper_args__ = {'concrete':True}
Manager(User):
__tablename__ = 'manager'
__mapper_args__ = {'concrete':True}
How is user going to be able to maintain the relationship with address
without a table, especially because the relationships are statically
defined using the class/table names? And what would be the best possible
solution in this case?
Regards
Loknath Bharti
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Inheritance, and tableless base class with relationship
On May 31, 2013, at 1:06 PM, developer.l...@gmail.com wrote:
Hi. I have the following structuring of classes with a base class without a
table.
User(base):
address = relationship('Address', backref=backref(user, uselist=False))
address_id = Column(Integer)
Address(base):
__tablename__ = 'address'
info = Column(String(255))
Info2 = Column(String(255))
Employee(User):
__tablename__ = 'employee'
__mapper_args__ = {'concrete':True}
Manager(User):
__tablename__ = 'manager'
__mapper_args__ = {'concrete':True}
How is user going to be able to maintain the relationship with address
without a table, especially because the relationships are statically defined
using the class/table names? And what would be the best possible solution in
this case?
its an awkward scenario that I'd try to avoid, but there's an illustration of
how to do this here:
http://docs.sqlalchemy.org/en/rel_0_8/orm/inheritance.html#relationships-with-concrete-inheritance
- note the relationship() is created explicitly on each child class. The
example includes a base table but that is optional.
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Query and compiled_cache
On Thu, May 30, 2013 at 3:28 PM, Claudio Freire klaussfre...@gmail.com wrote: On Thu, May 30, 2013 at 2:25 PM, Michael Bayer mike...@zzzcomputing.com wrote: On May 30, 2013, at 11:25 AM, Claudio Freire klaussfre...@gmail.com wrote: That way, one could use the second form up there and benefit from query hashing, because session/param binding wouldn't change the hash, and it would be a cache hit. Has it been explored already? Or maybe there's something wrong on how I'm using the compiled_cache thing? Should I start patching? ;-) there is a very wide gap between working with the baked query recipe, for which I'm not aware of all the errors you refer to so more detail would help Um... I don't remember the exact problems, will have to try it again. I just assumed it was targeted at an older SA release and gave up on it rather quickly. So, this is what I'm getting, which is weird: Traceback (most recent call last): File stdin, line 1, in module File /usr/local/lib64/python2.7/site-packages/chorde-0.1-py2.7-linux-x86_64.egg/chorde/decorators.py, line 184, in cached_f rv = f(*p, **kw) File metrics.py, line 291, in action_metrics if action is not None and action.campaign is not None: File /usr/local/lib64/python2.7/site-packages/SQLAlchemy-0.7.10-py2.7-linux-x86_64.egg/sqlalchemy/orm/attributes.py, line 458, in get value = self.callable_(state, passive) File /usr/local/lib64/python2.7/site-packages/SQLAlchemy-0.7.10-py2.7-linux-x86_64.egg/sqlalchemy/orm/strategies.py, line 481, in _load_for_state (mapperutil.state_str(state), self.key) sqlalchemy.orm.exc.DetachedInstanceError: Parent instance Action at 0x36f04d0 is not bound to a Session; lazy load operation of attribute 'campaign' cannot proceed With: class CacheableQuery(sqlalchemy.orm.query.Query): def __init__(self, *p, **kw): self._cached_context = None self._cached_context_labels = None super(CacheableQuery, self).__init__(*p, **kw) @sqlalchemy.orm.query._generative() def bake(self, labels=True): self._compile_context(labels) def _compile_context(self, labels=True): if self._cached_context and self._cached_context_labels == labels: context = super(CacheableQuery, self)._compile_context(labels) cached = self._cached_context context.statement = cached.statement else: context = super(CacheableQuery, self)._compile_context(labels) self._cached_context_labels = labels self._cached_context = context return context All the rest in baked query recipe is already supported by SA, so I didn't include it. Like with_session instead of from_session, and execution_options() instead of hardcoding a cache. Again, the usage is q = blabla.bake() ... q.with_session(S).params(..).first() I have no idea why replacing the query messes the entity's session. Any clue? -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Query and compiled_cache
On Fri, May 31, 2013 at 4:03 PM, Claudio Freire klaussfre...@gmail.comwrote: With: class CacheableQuery(sqlalchemy.orm.query.Query): def __init__(self, *p, **kw): self._cached_context = None self._cached_context_labels = None super(CacheableQuery, self).__init__(*p, **kw) @sqlalchemy.orm.query._generative() def bake(self, labels=True): self._compile_context(labels) def _compile_context(self, labels=True): if self._cached_context and self._cached_context_labels == labels: context = super(CacheableQuery, self)._compile_context(labels) cached = self._cached_context context.statement = cached.statement else: context = super(CacheableQuery, self)._compile_context(labels) self._cached_context_labels = labels self._cached_context = context return context Damn gmail With: . class CacheableQuery(sqlalchemy.orm.query.Query): . def __init__(self, *p, **kw): . self._cached_context = None . self._cached_context_labels = None . super(CacheableQuery, self).__init__(*p, **kw) . @sqlalchemy.orm.query._generative() . def bake(self, labels=True): . self._compile_context(labels) . . def _compile_context(self, labels=True): . if self._cached_context and self._cached_context_labels == labels: . context = super(CacheableQuery, self)._compile_context(labels) . cached = self._cached_context . context.statement = cached.statement . else: . context = super(CacheableQuery, self)._compile_context(labels) . self._cached_context_labels = labels . self._cached_context = context . . return context -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Query and compiled_cache
can you just attach a working .py script On May 31, 2013, at 3:06 PM, Claudio Freire klaussfre...@gmail.com wrote: On Fri, May 31, 2013 at 4:03 PM, Claudio Freire klaussfre...@gmail.com wrote: With: class CacheableQuery(sqlalchemy.orm.query.Query): def __init__(self, *p, **kw): self._cached_context = None self._cached_context_labels = None super(CacheableQuery, self).__init__(*p, **kw) @sqlalchemy.orm.query._generative() def bake(self, labels=True): self._compile_context(labels) def _compile_context(self, labels=True): if self._cached_context and self._cached_context_labels == labels: context = super(CacheableQuery, self)._compile_context(labels) cached = self._cached_context context.statement = cached.statement else: context = super(CacheableQuery, self)._compile_context(labels) self._cached_context_labels = labels self._cached_context = context return context Damn gmail With: . class CacheableQuery(sqlalchemy.orm.query.Query): . def __init__(self, *p, **kw): . self._cached_context = None . self._cached_context_labels = None . super(CacheableQuery, self).__init__(*p, **kw) . @sqlalchemy.orm.query._generative() . def bake(self, labels=True): . self._compile_context(labels) . . def _compile_context(self, labels=True): . if self._cached_context and self._cached_context_labels == labels: . context = super(CacheableQuery, self)._compile_context(labels) . cached = self._cached_context . context.statement = cached.statement . else: . context = super(CacheableQuery, self)._compile_context(labels) . self._cached_context_labels = labels . self._cached_context = context . . return context -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Query and compiled_cache
On Fri, May 31, 2013 at 4:44 PM, Michael Bayer mike...@zzzcomputing.comwrote: can you just attach a working .py script How does that work without a database? -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Recipe for text search across multiple fields
Hi, That's fixed it! I was so close :-) I was using mapper.order_by, which I'd hoped order_by(None) would cancel. No worries - it works now. This is in tw2.sqla DbListPage now, and I'll be putting updates in as I get round to it. Paul what's the purpose of cls.query.order_by(None) ? you're not using mapper.order_by i hope ? -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Query and compiled_cache
On Fri, May 31, 2013 at 4:47 PM, Claudio Freire klaussfre...@gmail.comwrote: On Fri, May 31, 2013 at 4:44 PM, Michael Bayer mike...@zzzcomputing.comwrote: can you just attach a working .py script How does that work without a database? Ok, I took one of SQLA's tests, and make it break ;) Notice the problem here is that I close the session after querying. Since the baked query has a joinedload, it shouldn't matter, but it does, because when baking, eager loads are broken somehow. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out. test_baked.py Description: Binary data
