| 00:35.30 | Busata | hm, when I do store.find(MarketOrder,(MarketOrder.orderID == order.orderID) & (MarketOrder.issued == datetime.utcfromtimestamp(order.issued))).one() , it works fine, when I use the same search query to update the object, it gives me a datetime error, any clues? |
| 00:48.57 | Busata | (AttributeError: type object 'datetime.datetime' has no attribute 'datetime' being the error) |
| 01:02.49 | *** join/#storm fcorrea (n=fcorrea@189.62.24.212) |
| 03:17.19 | *** join/#storm Busata (n=Dries_De@dD5774E1D.access.telenet.be) |
| 03:45.48 | jamesh | Busata: if you can paste the full traceback at http://paste.ubuntu.com I might be able to help |
| 03:57.18 | *** join/#storm bigdog3 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 05:26.33 | *** join/#storm bigdog1 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 06:54.13 | *** join/#storm thumper (n=tim@canonical/launchpad/thumper) |
| 08:09.12 | Busata | jamesh: http://pastebin.ubuntu.com/194125/ |
| 08:15.32 | Busata | the problem is , I pull data from an api, and the id's it gives me for those marketorders(orderID) isn't guarantueed to be unique forever, so I use it in combination with the date it got issued, finding objects like that works fine, but not sure why updating fails |
| 08:16.06 | jamesh | Busata: I've got a branch of Storm that might fix that problem for you |
| 08:16.38 | jamesh | https://code.launchpad.net/~jamesh/storm/bug-349482 |
| 08:18.34 | jamesh | you can grab it using Bazaar with "bzr branch lp:~jamesh/storm/bug-349482 storm" |
| 08:19.49 | Busata | ok, no experience with that, so hold on, but thanks alot already :) |
| 08:24.07 | jamesh | that branch should get merged to trunk for the next Storm release |
| 08:31.18 | Busata | awesome, that fixed it, thanks |
| 09:17.22 | *** part/#storm Busata (n=Dries_De@dD5774E1D.access.telenet.be) |
| 09:23.16 | *** join/#storm oubiwann_ (n=oubiwann@97-119-81-240.omah.qwest.net) |
| 09:43.40 | tlynn | I'm getting "ProgrammingError: could not serialize access due to concurrent update". Sure, that can happen, but how do I make Storm retry? |
| 09:44.01 | tlynn | I see from https://bugs.launchpad.net/storm/+bug/149335 that ProgrammingError isn't listed as one to retry |
| 09:44.03 | mup | Bug #149335: Should be easy to implement a transaction retry policy <Storm:New> <https://launchpad.net/bugs/149335> |
| 09:44.37 | tlynn | by "should be easy to", is that the same as "should not be impossible to"? |
| 09:46.22 | tlynn | (I see that SQLAlchemy also throws in the towel in the face of implementing retry logic) |
| 10:00.58 | tlynn | ZPsycopgDA does this for PostgreSQL by looking in the error string for "concurrent update": http://markmail.org/thread/2gqywuwy7bizpycz |
| 10:02.42 | *** join/#storm goschtl (n=goschtl@p5B0BBD5A.dip.t-dialin.net) |
| 10:08.39 | *** join/#storm Busata (n=Dries_De@dD5774E1D.access.telenet.be) |
| 10:17.35 | *** join/#storm jukart (i=lovely@81.189.156.94) |
| 10:51.44 | *** join/#storm gord (n=gord@xvm-14-110.ghst.net) |
| 12:11.46 | jamesh | tlynn: Storm is not in a position to retry exceptions -- it doesn't have enough information to know how to. You need to write your app such that you can rerun the relevant code |
| 12:12.24 | jamesh | and if you update your psycopg2 (highly recommended), you should get a more specific exception for this case. |
| 13:31.23 | *** join/#storm jukart (n=jukart@d91-128-122-26.cust.tele2.at) |
| 13:40.20 | tlynn | jamesh: thanks for the psycopg2 tip. surely storm does have enough information though - it knows what SQL it emitted and where the transaction boundaries are |
| 13:40.43 | fcorrea | I am not sure if the retry policy is supposed to be part of storm itself. In the wsgi world, there is repoze.retry which will retry to commit a transaction according to a given configuration |
| 13:40.54 | fcorrea | but yeah, you have a transaction manager in place as well |
| 13:42.08 | therve | tlynn: storm doesn't keep track of emitted SQL |
| 13:43.06 | radix | also, just re-executing SQL isn't a very good solution |
| 13:43.14 | radix | you really want to re-execute your application request handler |
| 13:43.22 | tlynn | well, I don't want my hooks to run twice |
| 13:45.10 | tlynn | but I suppose if there's a logical collision in the database I probably should find out about it |
| 13:45.42 | jamesh | tlynn: the database will be in a different state when you are retrying the transaction. |
| 13:46.00 | jamesh | and if it was as simple as re-executing the same SQL, the database would probably just do that ... |
| 13:46.13 | tlynn | fair point |
| 13:47.37 | jamesh | if you've got side effects mixed in with the transactional code, you'll have problems, yes. |
| 13:48.07 | jamesh | ideally you should defer those actions, and only perform them if the transaction commits successfully |
| 13:48.23 | tlynn | fortunately it's easy to put retry into my code right now, so I shall say no more about it, but it sounds like you're right. you might want to put something about that into the tutorial, since it's quite an important design constraint |
| 13:49.02 | jamesh | or design the app such that it doesn't matter if those actions occur spuriously |
| 13:49.12 | tlynn | yep |
| 14:04.02 | seiflotfy | last_entry = self.store.find(Event, Event.app == app.item.id).order_by(Desc(Event.start)).one() |
| 14:04.05 | seiflotfy | is that right |
| 14:04.20 | seiflotfy | it tells me resultset does not support the one method |
| 14:21.32 | seiflotfy | guy |
| 14:21.33 | seiflotfy | ? |
| 14:21.36 | seiflotfy | guys? |
| 14:23.46 | radix | seiflotfy: can you be more specific about what the error message is? |
| 14:25.44 | seiflotfy | NotOneError: one() used with more than one result available |
| 14:26.19 | therve | seiflotfy: can you read that a few times? |
| 14:26.55 | seiflotfy | ok let me put it liek that |
| 14:26.59 | radix | also maybe read the docstring |
| 14:27.27 | radix | you might want to use .first() instead of .one() |
| 14:29.27 | tlynn | or .config(limit=1) |
| 15:50.53 | *** join/#storm WebMaven (n=webmaven@c-68-35-136-143.hsd1.nm.comcast.net) |
| 22:37.34 | *** join/#storm Busata (n=Dries_De@dD5776017.access.telenet.be) |