[sqlalchemy] Re: pymssql and encoding - I can not get \x92 to be an '
...and while I'm making this thread unnecessarily long, I should add that
while pymssql may not understand Unicode data, the pyodbc DB-API interface
does. Thanks to recent work by Paul Johnston, it's on fast-track to becoming
the preferred MSSQL db-api for SA.
On 4/10/07, Rick Morrison [EMAIL PROTECTED] wrote:
Arghh, that last bit should be chr(146), not ord(146)
On 4/10/07, Rick Morrison [EMAIL PROTECTED] wrote:
You've got hi-bit characters in your data. MSSQL with pymssql will store
this, but not understand it.
You most likely are looking for a normal ASCII apostrophe (i.e.
ord(39)) instead of the hi-bit version you've got.
to get it, try ${str}.replace(ord(146), ')-- that last bit is a
single quote (apostrophe) surrounded by double-quotes
Rick
On 4/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hello all -
Unfortunately, we have a ms sql server at work. When I get tuples
from the server they look like this:
.. (55, 26, 'Small Business and Individual Chapter 11s - The NewCode
\x92s Effect on Strategies', 'AUDIO'...
with \x92 for apostrophe etc. I've tried putting every encoding in
the create_engine statement, including ISO-8859-1 used by MS SQL, but
the print statements always come out like:
.. The NewCode?s Effect on ..
I also tried passing the string to unicode(string, 'ISO-8859-1'), but
this gives me:
.. UnicodeEncodeError: 'ascii' codec can't encode character u'\x96' in
position 48: ordinal not in range(128) ..
Does anyone know about MSSQL or this encoding, or how to get
apostrophes where \x92 is?
Any help would be greatly appreciated.
-Steve
--~--~-~--~~~---~--~~
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] commit happening but, no changes in the database!
Hi,
I have this following code in my Turbogears which implements
nested_sets based msgboard. Each post has its own msg board, so
instead of locking the msgboard table itself, i lock the parent post's
row while editing the msgboard table.
msg_parents is the parent table.
msg_board is the table with all nested set heirarchy tables.
e
c = session.connect(None)
t = c.begin()
# Execute the insert on the msg_board_data table with lock
held on parent table's row
l = metadata.engine.text(SELECT id from %(parenttable)s
where id = :parent_id for UPDATE;
UPDATE %(table)s SET rgt=rgt + 2
WHERE rgt = :insert_node_val and parent_id = :parent_id;
UPDATE %(table)s SET lft=lft + 2
WHERE lft = :insert_node_val and parent_id = :parent_id;
INSERT INTO %(table)s (parent_id,
topic, content, depth, author_id, rank, lft, rgt, created, updated)
values(:parent_id, :topic, :content, :depth, :author_id,
:rank, :insert_node_val, :insert_node_val + 1, NOW(), NOW());
% {'parenttable':
self.parent_table_name, 'table': table.name},
bindparams=[bindparam('insert_node_val', type=types.Integer),
bindparam('parent_id', type=types.Integer),
bindparam('depth', type=types.Integer),
bindparam('topic', type=types.String),
bindparam('content', type=types.String),
bindparam('rank', type=types.Integer),
bindparam('author_id', type=types.Integer)
]
)
l.execute(table_name=table.name, depth=self.depth+1,
insert_node_val=self.rgt,
parent_id=self.parent_id, topic=topic,
rank=self.rank, content=content, author_id=author_id)
t.commit()
I'm using mysql, and i start a transaction, so the select..update
doesn't autocommit. This way i have a lock on that row.
then i'm updating rgt/lgt values for a whole bunch of rows. Finally, i
do a commit to save all change.s
The controller exits fine without errors, but i dnot see any changes
showing in the db! its very strange issue! Here is the log i see thru
metadata.engine.echo = True
2007-04-10 23:48:15,508 sqlalchemy.engine.base.Engine.0x..74 INFO
BEGIN
2007-04-10 23:48:15,513 sqlalchemy.engine.base.Engine.0x..74 INFO
SELECT id from msg_parents where id = %s for UPDATE; UPDATE msg_board
SET rgt=rgt + 2 WHERE rgt = %s and parent_id = %s; UPDATE msg_board
SET lft=lft + 2 WHERE lft = %s and parent_id = %s; INSERT INTO
msg_board (parent_id, topic, content, depth, author_id, rank, lft,
rgt, created, updated) values(%s, %s, %s, %s, %s, %s, %s, %s + 1,
NOW(), NOW());
2007-04-10 23:48:15,513 INFO sqlalchemy.engine.base.Engine.0x..74 [1L,
2L, 1L, 2L, 1L, 1L, 'topic', 'sadfasdfasdfdasf', 1L, 10010, 1L, 2L,
2L]
2007-04-10 23:48:15,521 INFO sqlalchemy.engine.base.Engine.0x..74
COMMIT
anyone know whats going on wrong here?
thanks.
--~--~-~--~~~---~--~~
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: [PATCH] Filtered one_to_many relationships (Experimental)
On 4/10/07, Michael Bayer [EMAIL PROTECTED] wrote:
hm, why is from_attr a classmethod ?
Because that way, you don't have to specify the related class at all,
and you can specify the parameters as args not kwargs. See my first
initial remark:
* I've implemented Query.from_attr, instead of adding new keywords to
the Query constructor, because I think:
Query.from_attr(someuser, 'addresses')
looks better, is shorter and is more readable than:
Query('Address', instance=someuser, attr_name='addresses')
not very consistent with all the other generative methods ?
True, but I think it makes more sense this way (see below).
can we have a regular generative method as well ?
If you really want one, I'll gladly do it, but I don't think it makes
sense because that method can possibly change the mapper.
So, first I'd need to duplicate part of what is in the __init__
method, which doesn't feel right.
And second, I think it could be quite confusing for a user. Imagine
that Query(A).from_attr(inst, 'rel') could return instances of B (or
whatever class is attached to the relation)... Probably not what you'd
expect. So, if we go down that route, it would probably be a good idea
to check that the mapper in the cloned query is the same than the one
we get from the relation.
And by the way, from_attr doesn't sound like a generative method, so
if you want it, what about filter_from_attr, or something similar?
--
Gaëtan de Menten
http://openhex.org
--~--~-~--~~~---~--~~
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: [PATCH] Filtered one_to_many relationships (Experimental)
is from_attr makeing sense for plain atributes, e.g. integers ot
whatever?
if no, maybe choose something like from_relation or filter_relation or
filter_relation_tomany or similar if it is expected to only work over
relations - and multiple-instances relations; i.e. it is useless over
single pointer-like 1:1 relation - so the name would suggest the
proper target-type.
On Wednesday 11 April 2007 11:50:53 Gaetan de Menten wrote:
On 4/10/07, Michael Bayer [EMAIL PROTECTED] wrote:
hm, why is from_attr a classmethod ?
Because that way, you don't have to specify the related class at
all, and you can specify the parameters as args not kwargs. See my
first initial remark:
* I've implemented Query.from_attr, instead of adding new keywords
to the Query constructor, because I think:
Query.from_attr(someuser, 'addresses')
looks better, is shorter and is more readable than:
Query('Address', instance=someuser, attr_name='addresses')
not very consistent with all the other generative methods ?
True, but I think it makes more sense this way (see below).
can we have a regular generative method as well ?
If you really want one, I'll gladly do it, but I don't think it
makes sense because that method can possibly change the mapper.
So, first I'd need to duplicate part of what is in the __init__
method, which doesn't feel right.
And second, I think it could be quite confusing for a user. Imagine
that Query(A).from_attr(inst, 'rel') could return instances of B
(or whatever class is attached to the relation)... Probably not
what you'd expect. So, if we go down that route, it would probably
be a good idea to check that the mapper in the cloned query is the
same than the one we get from the relation.
And by the way, from_attr doesn't sound like a generative method,
so if you want it, what about filter_from_attr, or something
similar?
--~--~-~--~~~---~--~~
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] session.expunge() detaches all objects recursively?
Hi Guys, not tried but quick answer would help me: session.expunge()'ing an object would also expunge the child attributes which are relations ? e.g. expunging User object would also expunge user_addresses (a list of UserAddress object) ? Also, if I make any modification in the detached instance both to User and the User Address child attributes within the object and then try to attach and flush will propagate the changes to both the parent and child table -- right ? thx. - A --~--~-~--~~~---~--~~ 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: 'PropertyLoader' object has no attribute 'strategy'
Roger Demetrescu wrote:
On 4/11/07, King Simon-NFHD78 [EMAIL PROTECTED] wrote:
I've got no idea about the source of the problem, but it
would probably
be helpful if you could provide stack traces from the exceptions, if
that's possible.
Do you mean using the traceback module ? I've just searched about it
and I guess I should use this:
try:
# do my stuff
except:
traceback.print_exc(file=sys.stdout)
raise
Is this the best way to show the stack trace ?
That would be one way to do it. If you are using the python logging
module, another way would be to use the logger.exception method, which
automatically adds the exception info, including the traceback, into the
log message.
Ie.
try:
# do your stuff
except:
logging.exception('Oops, an exception occurred')
# or use your_logger_instance.exception
raise
Other than that, I would have thought you should be able to
track down
the source of the 'global name' exception by grepping your
source code
for uses of 'anxnews_urllocal' without a '.' in front of it. Is it
possible that you are doing something like this, for example:
query.select_by(anxnews_urllocal 5)
When you probably mean:
query.select_by(table.c.anxnews_urllocal 5)
Man, you got it !! :)
The only line of my simple code that have a anxnews_urllocal without
a preceding . is here:
if anexo.anxnews_tipof == Anexo.IMAGEM:
cronometro.start()
renamed, size = _gerar_thumbs(local,
SIZE_WEB, SIZE_THUMB)
if renamed:
anexo.anxnews_urllocal =
posixpath.splitext(anxnews_urllocal)[0] + .jpg
This renamed condition is very rare... It only occurs when I'm
dealing with a BMP image...
And my log file confirms that.. I was manipulating a BMP image... :D
So I'm changing splitext(anxnews_urllocal) to
splitext(anexo.anxnews_urllocal)
Hope that helps,
It sure helped...
Thanks !
Roger
Well, it certainly makes a change - normally I'm the one asking the
questions ;-)
--~--~-~--~~~---~--~~
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: [PATCH] Filtered one_to_many relationships (Experimental)
On 4/11/07, svilen [EMAIL PROTECTED] wrote:
is from_attr makeing sense for plain atributes, e.g. integers ot
whatever?
You got a point here. It doesn't work (or even make sense) on plain attributes.
if no, maybe choose something like from_relation
Fine with me.
or filter_relation or
filter_relation_tomany or similar if it is expected to only work over
relations - and multiple-instances relations; i.e. it is useless over
single pointer-like 1:1 relation - so the name would suggest the
proper target-type.
It works fine for to_one relations. I'm not sure if anybody will
ever use it on such relations, but since it works as expected, I see
no reason to artificially constrain the thing to to_many
relationships.
On Wednesday 11 April 2007 11:50:53 Gaetan de Menten wrote:
On 4/10/07, Michael Bayer [EMAIL PROTECTED] wrote:
hm, why is from_attr a classmethod ?
Because that way, you don't have to specify the related class at
all, and you can specify the parameters as args not kwargs. See my
first initial remark:
* I've implemented Query.from_attr, instead of adding new keywords
to the Query constructor, because I think:
Query.from_attr(someuser, 'addresses')
looks better, is shorter and is more readable than:
Query('Address', instance=someuser, attr_name='addresses')
not very consistent with all the other generative methods ?
True, but I think it makes more sense this way (see below).
can we have a regular generative method as well ?
If you really want one, I'll gladly do it, but I don't think it
makes sense because that method can possibly change the mapper.
So, first I'd need to duplicate part of what is in the __init__
method, which doesn't feel right.
And second, I think it could be quite confusing for a user. Imagine
that Query(A).from_attr(inst, 'rel') could return instances of B
(or whatever class is attached to the relation)... Probably not
what you'd expect. So, if we go down that route, it would probably
be a good idea to check that the mapper in the cloned query is the
same than the one we get from the relation.
And by the way, from_attr doesn't sound like a generative method,
so if you want it, what about filter_from_attr, or something
similar?
--
Gaëtan de Menten
http://openhex.org
--~--~-~--~~~---~--~~
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: 'PropertyLoader' object has no attribute 'strategy'
On 4/11/07, King Simon-NFHD78 [EMAIL PROTECTED] wrote:
Roger Demetrescu wrote:
Do you mean using the traceback module ? I've just searched about it
and I guess I should use this:
try:
# do my stuff
except:
traceback.print_exc(file=sys.stdout)
raise
Is this the best way to show the stack trace ?
That would be one way to do it. If you are using the python logging
module, another way would be to use the logger.exception method, which
automatically adds the exception info, including the traceback, into the
log message.
Ie.
try:
# do your stuff
except:
logging.exception('Oops, an exception occurred')
# or use your_logger_instance.exception
raise
Cool... I am using python logging... I'll try your suggestion... :)
Thanks again,
Roger
--~--~-~--~~~---~--~~
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: ORM dynamic query ?
Do it with a mapping dict, for example: orders = dict ( la_name = la_name.c.name, en_name = en_name.c.name, group = groups.c.name, habitat = q.c.habitats, since = species.c.obs_belgium, georange = species.c.geographic_range, category = species.c.category_list) q = foo.select(..., order_by=orders.get(your_param_str)) Arun Kumar PG wrote: Guys, I have a search form and I want to compose the select_by() query dynamically as per the prameters but the select_by() on query object does not accepts string type query i.e. session.query(User).select_by( User.c.Id http://User.c.Id == 1 and ...) how can I achieve this ? thx in advance. - A -- Julien Cigar Belgian Biodiversity Platform http://www.biodiversity.be Université Libre de Bruxelles (ULB) Campus de la Plaine CP 257 Bâtiment NO, Bureau 4 N4 115C (Niveau 4) Boulevard du Triomphe, entrée ULB 2 B-1050 Bruxelles office: [EMAIL PROTECTED] home: [EMAIL PROTECTED] biobel reference: http://biobel.biodiversity.be/biobel/person/show/471 --~--~-~--~~~---~--~~ 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] Bit strange - no expunge required?
Hi Guys, I am having two layers in my application: Manager and DAO. DAO deals with ORM and manager simply calls method on DAO. This is what I am doing in manager manager: rs = dao.getResults(params) obj = rs[0] some logic. obj.name = 'some name' dao.Update(obj) The getResults() in DAOis implemented like this: def getResults(params): s = create_session() rs = s.query() return rs def Update(obj) s = create_session() s.update(obj) s.flush() As per the sqlalchemy documentation, we should explicitly expunge() the object and then use it with different session. The above logic works fine even when the object gettting updated actually belongs to the session that was created in the getResults() call. When I do the same on Python interactive interpreter prompt *without having the above methods* it throws: raise exceptions.InvalidRequestError(Object '%s' is already attached to session '%s' (this is '%s') % (repr(obj), old, id(self))) Can anyone help here. - A --~--~-~--~~~---~--~~ 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: pymssql and encoding - I can not get \x92 to be an '
Last I heard, pyodbc was working on any POSIX system that supports odbc (most likely via unixodbc or iodbc) http://sourceforge.net/projects/pyodbc/ -- check out the supported platforms On 4/11/07, Marco Mariani [EMAIL PROTECTED] wrote: Rick Morrison wrote: ...and while I'm making this thread unnecessarily long, I should add that while pymssql may not understand Unicode data, the pyodbc DB-API interface does. Thanks to recent work by Paul Johnston, it's on fast-track to becoming the preferred MSSQL db-api for SA. Since he starts with unfortunately, we have a ms sql server at work, maybe he's not developing on windows, and pyodbc is windows-specific. I think the data could be encoded with the 1252 charset, which is similar to 8859-1 but has an apostrophe in chr(146) --~--~-~--~~~---~--~~ 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: session.expunge() detaches all objects recursively?
cool. thx Michael! On 4/12/07, Michael Bayer [EMAIL PROTECTED] wrote: On Apr 11, 2007, at 7:27 AM, Arun Kumar PG wrote: Hi Guys, not tried but quick answer would help me: session.expunge()'ing an object would also expunge the child attributes which are relations ? e.g. expunging User object would also expunge user_addresses (a list of UserAddress object) ? expunge is part of the all cascade on a relationship, so if you have a cascade of all set up then an expunge operation will also follow along that relationship. Also, if I make any modification in the detached instance both to User and the User Address child attributes within the object and then try to attach and flush will propagate the changes to both the parent and child table -- right ? if you have save-update cascade turned on, which is the default setting and is also part of the all cascade. --~--~-~--~~~---~--~~ 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: IN() bug bit hard
On Apr 11, 6:05 pm, Rick Morrison [EMAIL PROTECTED] wrote: Most of the way it works is great: col.in_(v1, v2, v2) COL IN (v1, v2, v3) col.in_(v1) COL = v1 but this one: col.in_() COL IS NULL is a mapping I don't think is right. In our case, it caused an unexpected enormous table scan that loaded over 800MB of data and set our server to swapping. I'd say this is a definite bug. The semantics of col.in_(list) should be column value equals any of the values in the list. For an empty list it should be a constant false, because no value exists in an empty list, not even an missing value (null). What makes it a bit tricky is the fact that for null values the result should actually also be null. When straight .in_() is used it doesn't really matter, but when the negation is used then it starts to matter. That's because not_(col.in_()) should be the equivalent of COL IS NOT NULL. I think the best way would be to compile it to COL != COL, it has the correct behaviour when negated as well as not negated. Diff follows: Index: lib/sqlalchemy/sql.py === --- lib/sqlalchemy/sql.py (revision 2494) +++ lib/sqlalchemy/sql.py (working copy) @@ -895,5 +895,5 @@ def in_(self, *other): if len(other) == 0: -return self.__eq__(None) +return self.__ne__(self) elif len(other) == 1 and not hasattr(other[0], '_selectable'): return self.__eq__(other[0]) Ants --~--~-~--~~~---~--~~ 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: 'PropertyLoader' object has no attribute 'strategy'
On Apr 11, 2007, at 1:46 AM, Roger Demetrescu wrote: Hi all, I have a daemon with 2 threads to control upload / download of some files (they use SQLAlchemy to find out which files must be worked). Once a week, my daemon's logging system sends me an email with this message: 'PropertyLoader' object has no attribute 'strategy' After that, I receive another email with this message: global name 'anxnews_urllocal' is not defined where 'anxnews_urllocal' is a field from a table. I usually don't need to touch this daemon... it still works fine even after this alert. Any hints about what could be causing this exception ? one or both of thread synchronization / module import based issues. id be curious to know if the PropertyLoader exception occurs within the Mapper.compile() method. I do have a mutex on that system to avoid concurrency issues when the mapper first compiles (its one of the only mutexes within all of SA), but you know how grumpy mutexes can be. --~--~-~--~~~---~--~~ 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: IN() bug bit hard
On Apr 11, 2007, at 11:05 AM, Rick Morrison wrote: So I was up until 2:30am last night chasing down what looked like a huge memory leak in our app, and it turned out to be what I think is a bug in the way that SA maps the in_() function to SQL syntax. Most of the way it works is great: col.in_(v1, v2, v2) COL IN (v1, v2, v3) col.in_(v1) COL = v1 but this one: col.in_() COL IS NULL it has two optimizations like this in thereif you say col.in_ (x) it generates col == x. i dont think i have a problem whacking both of those and having it just say IN in all cases. we also have some open tickets for IN involving binds that i havent gotten around to. --~--~-~--~~~---~--~~ 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: ORM dynamic query ?
On Apr 11, 2007, at 9:56 AM, Arun Kumar PG wrote:
Guys,
I have a search form and I want to compose the select_by() query
dynamically as per the prameters but the select_by() on query
object does not accepts string type query i.e. session.query
(User).select_by( User.c.Id == 1 and ...)
the specific thing you want to do there would look like:
session.query(User).select_by(text( User.c.Id == 1 and ...))
but maybe you mean:
session.query(User).select_by(**{id: 1, foo : bar})
?
--~--~-~--~~~---~--~~
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: Bit strange - no expunge required?
On Apr 11, 2007, at 11:45 AM, Arun Kumar PG wrote: Hi Guys, I am having two layers in my application: Manager and DAO. DAO deals with ORM and manager simply calls method on DAO. This is what I am doing in manager manager: rs = dao.getResults (params) obj = rs[0] some logic. obj.name = 'some name' dao.Update(obj) The getResults() in DAOis implemented like this: def getResults(params): s = create_session() rs = s.query() return rs def Update(obj) s = create_session() s.update(obj) s.flush() As per the sqlalchemy documentation, we should explicitly expunge() the object and then use it with different session. The above logic works fine even when the object gettting updated actually belongs to the session that was created in the getResults() call. When I do the same on Python interactive interpreter prompt *without having the above methods* it throws: raise exceptions.InvalidRequestError(Object '%s' is already attached to session '%s' (this is '%s') % (repr(obj), old, id(self))) most likely that the session created in getResults() is falling out of scope in your application, therefore the entity is no longer attached to it (the operation thats throwing that error looks at a session_id attached to the object, looks in a WeakValueDictionary for that key to get the session). variable scope is more sticky in the python interpreter. --~--~-~--~~~---~--~~ 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: commit happening but, no changes in the database!
On Apr 11, 2007, at 3:05 AM, tml wrote: c = session.connect(None) t = c.begin() # Execute the insert on the msg_board_data table with lock held on parent table's row l = metadata.engine.text(SELECT id from %(parenttable)s ... l.execute(table_name=table.name, depth=self.depth+1, insert_node_val=self.rgt, parent_id=self.parent_id, topic=topic, rank=self.rank, content=content, author_id=author_id) t.commit() your l text query has no relationship to the Connection you've pulled out from session.connect() and therefore no relation to the Transaction youve begun on it. calling its execute() method uses a brand new connection. see the section on implicit and explicit execution context in the docs (you generally dont want to mix the two approaches). --~--~-~--~~~---~--~~ 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: IN() bug bit hard
On Apr 11, 2007, at 3:22 PM, Ants Aasma wrote: I'd say this is a definite bug. The semantics of col.in_(list) should be column value equals any of the values in the list. For an empty list it should be a constant false, because no value exists in an empty list, not even an missing value (null). What makes it a bit tricky is the fact that for null values the result should actually also be null. When straight .in_() is used it doesn't really matter, but when the negation is used then it starts to matter. That's because not_(col.in_()) should be the equivalent of COL IS NOT NULL. I think the best way would be to compile it to COL != COL, it has the correct behaviour when negated as well as not negated. Diff follows: Index: lib/sqlalchemy/sql.py === --- lib/sqlalchemy/sql.py (revision 2494) +++ lib/sqlalchemy/sql.py (working copy) @@ -895,5 +895,5 @@ def in_(self, *other): if len(other) == 0: -return self.__eq__(None) +return self.__ne__(self) elif len(other) == 1 and not hasattr(other[0], '_selectable'): return self.__eq__(other[0]) right well thats one way to look at it, i.e. that we should interpret the meaning of IN () in some special way. the current behavior is based upon my going with that approach a couple of years ago (and getting it wrong...suprise). but why dont we want to just have it compile just as it says - to IN () on the database side ? im not sure if trying to guess what the user means here is the best approach (refuse the temptation to guess...) --~--~-~--~~~---~--~~ 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: IN() bug bit hard
i vote no interpretation at all...if you want IN with one element, thats what youll get. no elements, ditto. also the bind param + etc ticket is #476. its got svilens artwork attached to it which i'd like to refine into a patch + unit test (but without the vis4check module/visitor thing...too complex..would rather have it just take ClauseElements unconditionally for now). On Apr 11, 2007, at 4:58 PM, Rick Morrison wrote: I think the singleton to equals is fine, but I'd be equally OK with a no surprises policy. I think the empty-list optimization should go, tho. On 4/11/07, Michael Bayer [EMAIL PROTECTED] wrote: On Apr 11, 2007, at 3:22 PM, Ants Aasma wrote: I'd say this is a definite bug. The semantics of col.in_(list) should be column value equals any of the values in the list. For an empty list it should be a constant false, because no value exists in an empty list, not even an missing value (null). What makes it a bit tricky is the fact that for null values the result should actually also be null. When straight .in_() is used it doesn't really matter, but when the negation is used then it starts to matter. That's because not_(col.in_()) should be the equivalent of COL IS NOT NULL. I think the best way would be to compile it to COL != COL, it has the correct behaviour when negated as well as not negated. Diff follows: Index: lib/sqlalchemy/sql.py === --- lib/sqlalchemy/sql.py (revision 2494) +++ lib/sqlalchemy/sql.py (working copy) @@ -895,5 +895,5 @@ def in_(self, *other): if len(other) == 0: -return self.__eq__(None) +return self.__ne__(self) elif len(other) == 1 and not hasattr(other[0], '_selectable'): return self.__eq__(other[0]) right well thats one way to look at it, i.e. that we should interpret the meaning of IN () in some special way. the current behavior is based upon my going with that approach a couple of years ago (and getting it wrong...suprise). but why dont we want to just have it compile just as it says - to IN () on the database side ? im not sure if trying to guess what the user means here is the best approach (refuse the temptation to guess...) --~--~-~--~~~---~--~~ 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: IN() bug bit hard
On Apr 11, 11:55 pm, Michael Bayer [EMAIL PROTECTED] wrote: but why dont we want to just have it compile just as it says - to IN () on the database side ? im not sure if trying to guess what the user means here is the best approach (refuse the temptation to guess...) Because that is not valid SQL. AFAIK the only database that implements it is Sqlite and there it behaves exactly as expr != expr. It's quite probable that users will try to use empty .in_(). The options are: a) immediately raise an error + errors are easy(er) to find - invalidates sqlite behaviour b) produce IN () SQL + 1:1 mapping between python and sql - most databases will give obscure errors, possibly far away from source of error - different behaviour between databases c) do a natural extension of SQL IN syntax + makes user code simpler in non negligible amount of cases + behaves the same in all databases - some one could possibly expect different semantics Did I miss anything? --~--~-~--~~~---~--~~ 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: IN() bug bit hard
On Apr 11, 2007, at 6:13 PM, Ants Aasma wrote: b) produce IN () SQL + 1:1 mapping between python and sql - most databases will give obscure errors, possibly far away from source of error well i dont think it would be a hard error to track down. the ORM doesnt use in_() so if an in_() happens, its because a user used it in their own code. - different behaviour between databases it would raise an error on most but SA tries to support DB idiosyncracies, like SQLite's accepting it c) do a natural extension of SQL IN syntax + makes user code simpler in non negligible amount of cases agreed + behaves the same in all databases agreed, as long as we know that saying somecolumn != somecolumn is valid and produces False on all dbs (including frequent-offenders firebird and ms-sql) ? (thats how you interpreted IN (), right ?) - some one could possibly expect different semantics yup, thats what im hoping to avoid. im still concerned we're just guessing here, and when users are surprised, its SA's job (i.e. mine, usually...) to then explain/justify but overall, i dont care much either way so leave my vote out of this one. --~--~-~--~~~---~--~~ 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] firebird engine patch for type_conv
patch against rev 2497
I believe type_conv only allows numeric values, so any type_conv opt
passed has to
be converted to an int. I bet the same rule applies to
concurrency_level, but this
patch doesn't address that.
(sorry, using google groups I can't see how to attach this as a file)
Index: /usr/local/src/sqlalchemy/lib/sqlalchemy/databases/firebird.py
===
--- /usr/local/src/sqlalchemy/lib/sqlalchemy/databases/
firebird.py (revision 2497)
+++ /usr/local/src/sqlalchemy/lib/sqlalchemy/databases/
firebird.py (working copy)
@@ -120,7 +120,7 @@
del opts['port']
opts.update(url.query)
-type_conv = opts.pop('type_conv', self.type_conv)
+type_conv = int(opts.pop('type_conv', self.type_conv))
concurrency_level = opts.pop('concurrency_level',
self.concurrency_level)
global _initialized_kb
if not _initialized_kb and self.dbapi is not None:
--~--~-~--~~~---~--~~
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: ORM dynamic query ?
Thx Michael.
this looks better but can't I do a join here and specify absolute column
names like {User.c.UserId..}
session.query(User).select_by(**{id: 1, foo : bar})
thx
- A
On 4/12/07, Michael Bayer [EMAIL PROTECTED] wrote:
On Apr 11, 2007, at 9:56 AM, Arun Kumar PG wrote:
Guys,
I have a search form and I want to compose the select_by() query
dynamically as per the prameters but the select_by() on query object does
not accepts string type query i.e. session.query(User).select_by(
User.c.Id == 1 and ...)
the specific thing you want to do there would look like:
session.query(User).select_by(text( User.c.Id == 1 and ...))
but maybe you mean:
session.query(User).select_by(**{id: 1, foo : bar})
?
--~--~-~--~~~---~--~~
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: Bit strange - no expunge required?
Hi Michael, So how can I prevent this as I can't access the lazyload attributes in my manager class once I get the result set from DAO as i get no parent session/contextual session exists exception. should I maintain a reference to the session object in the DAO class so that it is not garbage collected ? thx. - A On 4/12/07, Michael Bayer [EMAIL PROTECTED] wrote: On Apr 11, 2007, at 11:45 AM, Arun Kumar PG wrote: Hi Guys, I am having two layers in my application: Manager and DAO. DAO deals with ORM and manager simply calls method on DAO. This is what I am doing in manager manager: rs = dao.getResults (params) obj = rs[0] some logic. obj.name = 'some name' dao.Update(obj) The getResults() in DAOis implemented like this: def getResults(params): s = create_session() rs = s.query() return rs def Update(obj) s = create_session() s.update(obj) s.flush() As per the sqlalchemy documentation, we should explicitly expunge() the object and then use it with different session. The above logic works fine even when the object gettting updated actually belongs to the session that was created in the getResults() call. When I do the same on Python interactive interpreter prompt *without having the above methods* it throws: raise exceptions.InvalidRequestError(Object '%s' is already attached to session '%s' (this is '%s') % (repr(obj), old, id(self))) most likely that the session created in getResults() is falling out of scope in your application, therefore the entity is no longer attached to it (the operation thats throwing that error looks at a session_id attached to the object, looks in a WeakValueDictionary for that key to get the session). variable scope is more sticky in the python interpreter. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
