On Thursday, April 16, 2015 at 11:55:02 AM UTC-7, Anthony wrote: > > 1. To address your concern about "an attempted duplicate entry will end >> up raising an exception and returning a 500 response unless you catch and >> handle the error.", we could probably add something like this snippet at >> the (nearly) end of the "if form.accepts(...)" branch inside that >> register() in tools.py: >> >> try: >> db.commit() >> except Exception as e: >> db.rollback() >> response.flash = "Something is wrong. %s" % e # It is better >> than nothing >> > > We don't want to do explicit commits like this because that will commit > any previous operations as well, which means those operations would not be > rolled back in case there is a subsequent error (i.e., this violates the > principle that each request should be wrapped in a single transaction). >
OK, good point on explicit commits. Now I agree not to add that snippet into tools.py. But then, see below. > > 2. Even without above snippet, in our context I would say a rare >> 500-response-but-it-would-be-gone-if-you-simply-retry is (arguably?) still >> better than, silently creating duplicated user accounts which clearly >> violates the universal expectation of such a fundamental db scheme >> assumption. >> > > This doesn't seem to be a likely problem -- two different users would have > to be trying to register with the same username/email within milliseconds > of each other. On the other hand, I suppose this would make the 500 > response in such a case equally rare (assuming we set unique=True in the > table definition). > > Well, in my case, the delay was caused by sending email, so it is definitely not "milliseconds of each other". It takes some 2 or 3 seconds, maybe even longer. And during this period, it is not that another user would try to register with same username/email, it is somehow the same user request would (seemingly?) be resent (by the user's app or by my reverse proxy apache or by a wsgi middleware or whatever, which I don't know yet). As a result, I saw duplication actually happening in my db every now and then. FYI: Their creation time stamp vary among 1 to 3 seconds. Although I agree with your earlier suggestion to re-engineer the email sending part to a separated queue, which is a good idea indeed, but as a more general topic, I still think it would be good to have web2py to define unique=True for username and/or email in auth_user table by default. Personally I am willing to trade a rare (0.01%?) chance of a user-scary 500 error ticket for the 100% guarantee of no duplication in auth_user table. Don't you think so? -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
