Aún otro ejemplo de try, except, else, finally / Yet another try, except, else, finally example

Estaba pasando datos de una DB mysql a otra en django y me ha salido este "snippet" que ejemplifica el uso de try-except-else-finally.

try contiene el código que queremos proteger
except captura la excepción (usar la clase genérica exception para capturarlas todas)
else código que se ejecutará si no salta ninguna excepción
finally código que se ejecutará en todo caso tanto si hay como si no hay excepción

Las únicas obligatorias son try y except. Si queremos capturar más de una excepción, las ponemos una detrás de otra:

from django.core.exceptions import ObjectDoesNotExist
try:
    cl=Cliente.objects.get(clave=id)
except ObjectDoesNotExist, ex:
    print "el cliente no existe"
except Exception, ex:
    print "se ha producido un error", str(ex)

Ejemplo:


try:
try:
c=db_marcajes.cursor(MySQLdb.cursors.DictCursor)
c.execute("select id, fecha, event, door, user from logs where fecha>%s", (last_marcaje,))
rows=c.fetchall()
except Exception, e:
print "Impossible efectuar consulta"
exit(1)
else:
elapsed = (time.clock() - start)
print "Consulta realitzada en", elapsed, "msegs"
num_rows=len(rows)
print "Numero de filas ", num_rows
i=0
while i<num_rows:
row=rows[i]
print "procesando fila ", repr(row)
try:
em=Empleado.objects.get(pin=row['user'])
pt=Puerta.objects.get(pk=row['door'])
print ("guardando acceso %s de %s" % (row['user'],em.descripcion,))
except Exception, ex:
print ("Error de busqueda empleado %s puerta %s: %s", ( row['user'], row['door'], ex, ))
else:
try:
acc=Acceso(
empleado=em,
es=row['event'],
fecha=row['fecha'],
puerta=pt,
)
#acc.save()
print "Guardado"
except Exception, ex:
print ("Error grabando acceso: %s" % (ex,))
finally:
i+=1
last_marcaje=row['fecha']
finally:
c.close()
finally:
# guardam darrer marcatje
conv=Convenio.objects.get(pk=1)
conv.last_marcaje=last_marcaje
conv.save()

Prevenir el borrado de objetos via clave foránea / Prevent object deletion via foreign key

Una de los comportamientos por defecto más problemáticos de django es el de emular el DELETE CASCADE  cuando borramos una clave foránea. Desde luego, hay que ser animalito. Ya me veo a decenas de usuarios noveles preguntándose adonde han ido a parar sus datos después de efectuar un borrado de una clave foránea que tenía objetos relacionados.

La forma de "proteger" los objetos relacionados es via la definición del ForeignKey.on_delete que puede tomar los siguientes valores

CASCADE: Borrado en cascada, comportamiento por defecto.
PROTECT: Protege al objeto relacionado del borrado haciendo saltar la excepción django.db.models.ProtectedError.
SET_NULL: Asigna el valor null a la clave, sólo posible si null es True.
SET_DEFAULT: Pone la clave foránea a su valor por defecto (debe estar definido).
SET(): Asigna a la clave foránea el valor pasado en el set.
DO_NOTHING: No hace nada y deja el comportamiento por defecto de la db. (Si la hemos creado con syncdb, no hará nada)


Una práctica aconsejable en un entorno de usuario sería capturar la excepción via PROTECT y devolver un mensaje de error con la información para el usuario.Por ejemplo:

Si en la definición del modelo Factura usamos

cliente=models.ForeignKey(Cliente, on_delete=models.PROTECT)

Y ahora queremos borrar un cliente que tiene una factura asociada

try:
  cliente.delete()
except django.db.models.ProtectedError, ex:
  return HttpResponse( ('El cliente %s tiene al menos una factura y no puede borrarse.' % (cliente.descripcion,)), 'text/html')

subversion: volver a una versión anterior

Si estás modificando la versión 189 de tu código y quieres volver a la anterior, sólo tienes que hacer:


svn update
svn merge -r 189:188 .
svn commit -m "Volviendo a la version r188"

ubuntu no arranca una sesión X de usuario

Me ha ocurrido que de un momento para otro ubuntu no me deja abrir mi sesión. En cambio con otros usuarios si lo permite. Después de buscar toda una tarde la solución ha sido entrar por cónsola Ctrl+Alt+F1 y hacer

sudo mv ~/.Xauthority ~/.Xauthority.old