Django e Gulp

import gulp from 'gulp';

import plumber from 'gulp-plumber';
import pug from 'gulp-pug';
import browserSync from 'browser-sync';
import sass from 'gulp-sass';
import postcss from 'gulp-postcss';
import cssnano from 'cssnano';
import watch from 'gulp-watch';
import browserify from 'browserify';
import babelify from 'babelify';
import source from 'vinyl-source-stream';
import sourcemaps from 'gulp-sourcemaps';
import buffer from 'vinyl-buffer';

const server = browserSync.create();

const postcssPlugins = [
cssnano({
core: false,
 autoprefixer: {
add: true,
browsers: '> 1%, last 2 versions, Firefox ESR, Opera 12.1'
}
})
];

const sassOptions = {
outputStyle: 'expanded'
};

gulp.task('styles', () =>
gulp.src('./dev/scss/styles.scss')
.pipe(sourcemaps.init({ loadMaps: true }))
.pipe(plumber())
.pipe(sass(sassOptions))
.pipe(postcss(postcssPlugins))
.pipe(sourcemaps.write('.'))
.pipe(gulp.dest('../static/css'))
.pipe(server.stream({match: '**/*.css'}))
);

gulp.task('scripts', () =>
browserify('./dev/js/index.js')
.transform(babelify)
.bundle()
.on('error', function(err){
console.error(err);
this.emit('end')
})
.pipe(source('scripts.js'))
.pipe(buffer())
.pipe(sourcemaps.init({ loadMaps: true }))
.pipe(sourcemaps.write('.'))
.pipe(gulp.dest('../static/js'))
);

let reloadFiles = [
'../templates/*.html',
'../templates/**/*.html',
]

gulp.task('default', () => {
server.init(reloadFiles,{
proxy: 'http://localhost:8000/',
notify: false
});
watch('./dev/scss/**/*.scss', () => gulp.start('styles'));
watch('./dev/js/**/*.js', () => gulp.start('scripts',server.reload) );
});
Reducir consultas a la BD en el Admin
de Django
Cómo reduje de 25 a 5 consultas en una vista en el Admin de django
Lograr esto es un conjunto de técnicas tanto a nivel de código, como de lógica. Para ponernos en
contexto, explico el proyecto.
Miboda: Es un proyecto en django, que permite tener una App web para invitar a tus amigos a tu
boda.Ver la lista de invitados, confirmar asistencia, el invitado puede enlazarse a un usuario
registrado o ser “anónimo”. Así que los modelos principales son:
• Boda (permite configurar los datos de la boda, el novia (usuario), novia (usuario), mensaje
público, mensaje para usuarios invitados)
• Invitado (Guarda la información de un invitado, Usurio (opcional), Nombre, teléfono,
Asistencia, Quién lo invitó (otro invitado?), y más datos…)
El asunto es que en la vista de invitados en el Admin de Django, quiero mostrar: Nombre de
invitado, Boda, Invitado por, Asistencia.

Retornar valores locales en lugar de relacionados

Para empezar, el modelo Boda en su representación String (__str__) retornaba: “{Fecha}, {Novio}
y {Novia}”. Como Novio y Novia son referencias al modelo Usuario, por cada boda registrada,
hacía una cosulta para obtener el nombre del Novio y otra para el nombre de la Novia, así que si es
una sola boda registrada, ya había tres consultas. Si fuesen 10 serían 21 consultas. Así que, aunque
podía optar por hacer un Boda.objects.select_related(‘novio’, ‘novia’) (tal como se explica aquí),
decidí simplemente retornar un dato local del modelo Boda, en esta caso Fecha.
Así que si no es necesario, es mejor retornar datos locales de un modelo en lugar de
relacionados con el fin de optimizar la consulta.

Validar datos relacionados nulos desde un campo local

Una buena práctica es también validar si se asignó el valor a un dato relacionado, usando el campo
local.
Ejemplo: para verificar si a la boda, ya se le asignó el Novio podrías:
Con esto último haces referencia al campo local de la base de datos, y no será necesario hacer la
consultar hacia la tabla User para verificar si hay un Novio asignado. Obviamente para que esto
sucediese el campo novio debe tener en null=True, blank=True.

Sobreescribir el queryset de un ModelAdmin:

Es también buena práctica para optimizar la consulta:
En esta caso sobreescribí la función get_queryset para hacer uso de select_related, que permitirá
traer en una sola consulta los datos de Boda, Novio (relacionado al modelo User), Novia (user),
invitado (user) o Invito (invitado).
Observa que incluso puedes hacer referencia a los campos de un modelo, usando doble guion bajo.
En este caso Boda__novio hará un LEFT OUTER JOIN (porque son datos opcionales y puede ser
nulo) con User para traer los datos del Novio, lo mismo para novia, que traducido a SQL es:
SELECT ••• FROM "boda_invitado"
INNER JOIN "boda_boda" ON ("boda_invitado"."boda_id" = "boda_boda"."id")
LEFT OUTER JOIN "userman_user" ON ("boda_boda"."novio_id" =
"userman_user"."id")
LEFT OUTER JOIN "userman_user" T4 ON ("boda_boda"."novia_id" = T4."id")
LEFT OUTER JOIN "userman_user" T5 ON ("boda_invitado"."invitado_id" = T5."id")
LEFT OUTER JOIN "boda_invitado" T6 ON ("boda_invitado"."invito_id" = T6."id")
ORDER BY "boda_invitado"."invitado_id" ASC, "boda_invitado"."id" DESC

Esto es básicamente lo que más ahorra consulta a la base de datos, pues se traduce a join’s en SQL
y da como resultado una sola consulta.

Retornar el valor de una función desde list_display en admin.ModelAdmin

Es bien sabido que puedes crear una función en la clase admin.ModelAdmin. Te pongo un ejemplo:
Pero la función get_invitado también puede existir modelo. Y es mejor práctica que exista en el
modelo, porque se podrá hacer uso de ella desde cualquier lugar donde invoques al modelo. Si la
función existe en el admin y también en el modelo, django le da prioridad a la más próxima, en este
caso a la de InvitadoAdmin.
Usando django debug toolbar, pude medir la eficiencia de las consultas a la base de datos, y reducir
significativamente el número de ellas.
Estos son resultados a mis experimentos en Django, si tienes alguna sugerencia o corrección, la
espero con mucho gusto en los comentarios.