In my opinion you have the better approach for some cases. I think it is better to work under the assumption that the insert query will be successful, and catching any exceptions as reported by the db. I suppose it would also depend on what do you think will outlast the other - your database and data, or the front end framework. I'm working in environments where the data has been around for many years (15+), and has been accessed through a number of different front ends (written by varying levels of developers). In that case it was the database enforcing constraints that maintained good integrity. The nice thing about django models is that if written correctly they do add those constraints when creating the tables.
If the need is a quickly written web application which may not realistically be around for more than a couple of years, using the built in functions is the way to go until you actually start to observe some contention in the database - at which point look for opportunities for improvement. On the get_or_create issue, I suppose it would matter which do you think would occur more, new inserts or gets? It likely won't make much of a difference until you get a certain level of load on the server. Maybe you could write a similar function create_and_get which would first attempt to create the record, on exception get the one that already exists (using /django/db/models/query.py get_or_create as a starting point) or report back why the insert failed. This would avoid having to deal with MySQLError's throughout your application. Good discussion of this in Stéphane Faroult's 'The Art of SQL' ch2 (highly recommend this book to anyone trying to make better db applications). He calls it offensive/aggressive coding. On Jun 14, 10:41 am, Forest Bond <for...@alittletooquiet.net> wrote: > Hi, > > On Jun 13, 2:42 am, koepked <koep...@hotmail.com> wrote: > > > Is it bad practice to rely on db exceptions to indicate an attempt at > > writing duplicate values to a "keyed" column? For example, in some > > code I'm working on, I have the following: > > > x = ContentItem(title=e_title) > > > try: > > x.save() > > except MySQLError: > > x = ContentItem.objects.get(title=e_title) > > In this case, get_or_create does exactly what you want. However, > exceptions are almost always the right thing to use in these kinds of > situations. Looking for an existing object first and then continuing > after not finding one is vulnerable to race conditions. That is > called the "look before you leap" approach (or LBYL), while using > exceptions is called the "it's easier to ask for forgiveness than > permission" (or EAFP). This mailing list thread is a good read on the > subject: > > http://mail.python.org/pipermail/python-list/2003-May/205182.html > > To avoid the database-specific dependency, use > django.db.IntegrityError. > > -Forest --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
