[sqlalchemy] Getting quater wise result using date_part
Hi to everyone
I am using date_part to get data from PostgresSQL and i want to fetch
data quarter wise (Q!,Q2,Q3,Q4)
The query date_part('month', field name) in (1,2,3) works well in
postgres and fetch for first 3 months but how to put it in
sqlalchemy ...
I hope u got what i am asking for .
Pls help its urgent
Regards
ASB
--~--~-~--~~~---~--~~
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] concurent modification
Does someone have an idea how to fix the problem that cause this traceback : Exception in thread Thread-5: Traceback (most recent call last): File threading.py, line 442, in __bootstrap self.run() File ./camper.py, line 138, in run walk(session, theone, root) File ./camper.py, line 49, in walk session.flush() File /usr/lib/python2.4/site-packages/sqlalchemy/orm/scoping.py, line 74, in do return getattr(self.registry(), name)(*args, **kwargs) File /usr/lib/python2.4/site-packages/sqlalchemy/orm/session.py, line 683, in flush self.uow.flush(self, objects) File /usr/lib/python2.4/site-packages/sqlalchemy/orm/ unitofwork.py, line 209, in flush flush_context.execute() File /usr/lib/python2.4/site-packages/sqlalchemy/orm/ unitofwork.py, line 436, in execute UOWExecutor().execute(self, head) File /usr/lib/python2.4/site-packages/sqlalchemy/orm/ unitofwork.py, line 1055, in execute self.execute_save_steps(trans, task) File /usr/lib/python2.4/site-packages/sqlalchemy/orm/ unitofwork.py, line 1069, in execute_save_steps self.save_objects(trans, task) File /usr/lib/python2.4/site-packages/sqlalchemy/orm/ unitofwork.py, line 1060, in save_objects task.mapper.save_obj(task.polymorphic_tosave_objects, trans) File /usr/lib/python2.4/site-packages/sqlalchemy/orm/mapper.py, line 1123, in save_obj raise exceptions.ConcurrentModificationError(Updated rowcount %d does not match number of objects updated %d % (rows, len(update))) ConcurrentModificationError: Updated rowcount 0 does not match number of objects updated 1 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: deleting
You must istantiate an istance of the obj to be deleted. This is an Object Manager, so all operation is available on object. or you can execute a plain string-sql direclty from engine connection = engine.connect() connection.execute(DELETE FROM a WHERE b = c) or I can do this : f_table.delete(f_table.c.user_id==theone.id).execute() --~--~-~--~~~---~--~~ 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: merge with dont_load=True and lazy relations
Hi there - there are actually two bugs here, the second one is revealed after repairing the first. The first bug is that the merge() dont_load operation was not completing all the necessary housekeeping on the newly generated copy of the instance, such that the lazy loader for zone (or any other lazy loader) mistakenly detected that the instance had no mapper. this was an easy fix. The second bug is more complex, and its that the committed_state collection for the newly generated copy of the instance contained data from the unmerged copy, in this case the merged User contained the unmerged Address in its committed state. Since the new copy's own addresses collection contained the merged Address but not the unmerged one, the flush() would mistakenly update the unmerged address to not have any User object. At the moment I'd rather not get into the added complexity of regenerating a committed_state collection on the merged object which corresponds to exact changes made on the unmerged object. since the use case for dont_load=True is cached objects being brought into a session, they shouldn't have any pending changes on them anywayso for now I have it raising an error if you try to merge an entity that's marked as dirty, and the newly merged instances get a clean committed state. if someone is merging objects with pending changes its really best not to use dont_load anyway so that the committed_state collection represents the most recently available database state. comments welcome on this one as usual. These changes are in r3811. --~--~-~--~~~---~--~~ 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] merge with dont_load=True and lazy relations
Hi, I'm using SQLAlchemy 0.4.1. Th eproblem is reproducible with the following code: http://pastie.caboo.se/121057 As you can see, when merging an object with a lazy relation (here 'zone'), the 'zone' property is replaced with a fixed None value in the merge object (you can't load the property anymore by accessing it). Worst, when you flush the session, this None value is persisted, although the 'zone_id' property is not None. This (kind of a) bug does not occur if I use dont_load=False. Regards, Pierre-yves. --~--~-~--~~~---~--~~ 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: concurent modification
I think all one can do is just forget and start over again, when concurrent modifications error occurs. That means, catchig the exception and just showing some failure message to the user is all one can do. Sanjay --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
