#dbix::class

[plainblackguy]

Complicated joins with DBIx::Class

DBIx::Class is a great way to hide database interactions in your Perl classes. However, something that you might find easy in normal DBI queries can seem hard in DBIx::Class, because you lack direct access to the SQL. Take for example the following query:

select dayparts.name from eventtyperooms join slots on (eventtyperooms.room_id=slots.room_id) join dayparts on (slots.daypart_id = dayparts.id) where slots.is_reserved=0 and eventtyperooms.eventtype_id='E375219C-CDBB-11E5-8739-AFC57843E904' group by slots.daypart_id order by dayparts.start_date asc;

There are lots of joins going on here and not all of them are on primary keys. Plus we've got some other qualifiers in there. This is where search_related() can come to the rescue.

$eventtype->search_related('eventtyperooms') ->search_related('slots', {'slots.is_reserved' => 0}) ->search_related('daypart') ->search(undef, { group_by => 'slots.daypart_id', order_by => 'daypart.start_date' });

The above code will generate the following query:

SELECT `daypart`.`id`, `daypart`.`name`, `daypart`.`is_locked`, `daypart`.`start_date` FROM `eventtyperooms` `me` JOIN `slots` `slots` ON `slots`.`room_id` = `me`.`room_id` JOIN `dayparts` `daypart` ON `daypart`.`id` = `slots`.`daypart_id` WHERE `me`.`eventtype_id` = 'E375219C-CDBB-11E5-8739-AFC57843E904' AND `slots`.`is_reserved` = '0' GROUP BY `slots`.`daypart_id` ORDER BY `daypart`.`start_date`

This allows you to use all the existing relationships you've set up in your schema to do complex joins.

[davorg]

Public Training in London - February 2016

Public Training in London – February 2016

For several years I’ve been running an annual set of public training courses in London in conjunction with FLOSS UK (formerly known as UKUUG). For various scheduling reasons, we didn’t get round to running any this year, but we have already made plans for next year. I’ll be running five days of training in central London from 8th – 12th February. The courses will take place at the Ambassador’s…

View On WordPress

[cym0n-blog]

Migrazione completata

Sono riuscito a portare a termine il non banale compito di migrare tutta la logica di game sotto i Result.

Devo confessare che l'applicazione delle foreign key era propedeuito soprattutto a questo. La classe Element::Game, infatti, aveva un mucchio di spinotti che simulavano le relazioni tra le varie tabelle. Migrare tutto sotto Result::Game e portarmeli dietro sarebbe stato poco utile e assolutamente delirante.

Completate le foreign e attivate quindi le relationship anche sotto DBIx::Class ho potuto invece lavorare con un po' più cognizione di causa, trasformando un sacco di chiamate rimbalzanti tra una classe e l'altra in un'unica chiamata coerente.

In proposito della migrazione verso le foreign ho incontrato solo un piccolo ostacolo dovuto all'omonimia tra una delle relazioni generate e uno dei campi della mia tabella. C'è modo di uscirne senza modificare il nome della colonna? Forse si. Sicuramente si può semplicemente dare alla relazione un nome diverso da quello che sceglie da sola. Farlo, però significa pestare i piedi al dbicdump e la cosa non è che mi esalti mai, quindi alla fine ho creduto prendere la decisione corretta rinominando semplicemente la colonna.

Per il resto si è trattato di un grosso esercizio di copia incolla da una parte all'altra. Non credo che, a oggi, il codice sia perfetto, anzi, probabilmente nell'ansia di far funzionare tutto ho adottato alcune soluzioni proprio sporche, ma adesso ho un nuovo punto di partenza molto più solido da cui eseguire tutti i prossimi ragionamenti.

Questo lavoro fa emergere il problema che ci sono stati dell'applicativo che il mio sistema automatico non raggiunge e che servirebbero in quanto sono tra i più noiosi. Penso che ora mi dedicherò a questo, anche perché alcune cose proprio non le ho viste effettivamente funzionare e il dubbio rimane.

[cym0n-blog]

dbicdump success

Piccolo aggiornamento: ho lanciato lo script di dump delle tabelle. Per farlo andare innanzitutto ho dovuto farlo puntare a MySQL (prima tirava giù i dati dal SQLite) e poi ho dovuto eliminare il parametro quote_char che evidentemente veniva buono solo per SQLite.

A parte questi piccoli accorgimenti tutto il codice è stato rigenerato senza distruggere niente (il che mi conforta anche riguardo la pulizia che ho mantenuto nello sviluppo lato modello finora). Ovviamente ho già verificato che le nuove relazioni sono correttamente considerate dal perl.

Questo era il punto che mi metteva maggior ansia, sto scrivendo, in verità, senza sapere se ora è tutto rotto o se comunque il sito è comunque operativo, ma già vedere che tutto è stato correttamente recepito è un buon punto a favore dell'operazione.

Adesso abbiamo un mucchio di possibilità in più date da DBIx::Class, discendenti direttamente dall'uso delle relazioni... vediamo di usarle.

[cym0n-blog]

Passa lo straniero

Il refactoring che più mi spaventa è quello di installare tutte le relazioni tra le varie tabelle del sistema e poi usarle nel gioco.

E' un refactoring importante perché, oltre al tema dell'efficienza, può aiutarmi a capire meglio come ragiona DBIx::Class. 

La cosa che più mi rende nervoso riguardo la cosa è che io sono proprio un ignorante nello sviluppare i DB, anzi, a dirla tutta, i DB mi stanno proprio antipatici. E' stata quindi già una piccola impresa capire come fare ad appiccicare le foreign alle varie tabelle.

Scopro oggi, da bravo dilettante, che si può attaccare una foreign key solo a una colonna che sia indicizzata e solo a tabelle il cui engine sia InnoDB. 

Poiché le tabelle sono state create con engine di default (quindi MyISAM) la prima cosa da fare è stato produrre uno script che alterasse tutti gli engine. Una volta fatto ciò mi sono messo a censire tutti i collegamenti e ad aggiungerli. Riporto qui uno script d'esempio:

CREATE INDEX player ON GAMES (USER_ID); ALTER TABLE `GAMES` ADD FOREIGN KEY ( `USER_ID` ) REFERENCES `djakarta`.`USERS` (`ID` );

E' una cosa da cui non si torna indietro. Se passo a un'architettura del genere mi scordo di poter usare un SQLite di supporto. Mi sono quindi messo a riorganizzare le cartelle dei miei script e ho prodotto (ok, vergogna su di me, usando phpmyadmin) uno script di dump con tutta la struttura a oggi, che diventa anche un comodo sistema per ripristinare il sistema attuale o installarlo su un nuovo ambiente.

Accanto a questo dump, ora, ci sono anche tutti gli script per le modifiche, fortunatamente indipendenti tra loro e già installati sul mio ambiente locale.

La palla passa a DBIx::Class.

[cym0n-blog]

Refactoring con classe

Fino a oggi avevo una classe ..Element::User che era una classe vera e propria, che controllava l'oggetto user, è una classe Result::User che era, naturalmente la classe Result generata dallo schema del DB.

Andando avanti a sviluppare mi è risultato sempre più ovvio come la classe Element::User non fosse altro che un proxy verso il modello. Ho deciso quindi di fare del refactoring affinché tale classe cessi di esistere e tutto sia gestito dal Result.

Visto che comunque non è che User abbia molta logica è stato tutto estremamente lineare. La maggior parte dei metodi (quelli brutalmente proxy) sono stati semplicemente eliminati mentre gli altri copincollati con poche modifiche nel diverso punto.

L'unica logica un po' pesante su cui ho dovuto lavorare è stata quella contenuta nel new della classe Element::User che si portava dietro, ovviamente diversi ragionamenti. Tutta quella roba l'ho spostata in un metodo dei controllers, anche lì copiandola in modo abbastanza lineare e con pochi problemi.

Nel tentativo, infine, di testare la nuova implementazione con i test automatici, mi sono scontrato per l'ennesima volta col problema della configurazione dell'ambiente Dancer di riferimento. Ho cercato, cioè, di fare in modo che nel momento in cui viene eseguito un test automatico questo carichi un suo specifico yml di configurazione. Qualsiasi esempio trovato su internet ha fallito nel farmi fare una cosa del genere. Non mi rimane che lanciare il test con:

perl t/000X_test.t --environment=t

 Ora voglio, come cosa "facile" estendere il test perché il sistema arrivi alla vittoria e e poi come cosa "molto difficile" fare la stessa cosa di Element::User con Element::Game che però ha sicuramente molto più codice interessante...

[cym0n-blog]

Può dare dipendenza

Quando ti dicono come si comportano i bravi bambini, tra le altre cose, ti dicono di tenere traccia delle librerie che impieghi in un software, quantomeno per essere sicuro di replicare le attività di installazione in un ambiente diverso dal tuo. Come sempre chi dice queste cose ha ragione.

Tutti i miei problemi su openshift, a oggi, si sono rivelati essere problemi di librerie mancanti. Purtroppo non tutto può essere individuato semplicemente risalendo gli alberi delle dipendenze dei pacchetti perché sia Dancer che DBIx::Class usano certe euristiche e certi meccanismi introspettivi per assettare l'ambiente che si traducono in use impliciti.

Alla fine gli oggetti che ho dovuto esplicitamente dichiarare nel deplist.txt, oltre a quelli standar per un Dancer sono risultati:

Template Dancer::Session::Storable DBIx::Class::TimeStamp

Vergogna però cada su Dancer::Plugin::DBIC. Per debuggare ho dovuto entrare nella classe e cambiare il suo messaggio d'errore da:

 die "Could not load schema_class $schema_class" if $@;

a

 die "Could not load schema_class $schema_class $@" if $@;

 Magicamente così la classe mancante (Timestamp) è risultata subito evidente!

Ora il prossimo passo è creare la app Facebook relativa all'ambiente.

Musica nelle orecchie: http://www.youtube.com/watch?v=wc3f4xU_FfQ

[cym0n-blog]

I was waiting for you...

Dove eravamo rimasti con DjakaWeb?

All'implementazione della logica facebookosa del click. Ovvero quell'antipatica (ma facebookosa, quindi splendida) meccanica per cui "giocare" significa presentarsi ogni tot ore su un sito e fare un click.

DjakaWeb comprende numerose azioni che si possono fare. Si potrebbe ridurre una "partita" a quindici minuti consentendo all'utente di fare tutte le azioni di seguito, ma noi vogliamo che le azioni abbiano un "prezzo" in senso di tempo (facebookoso) quindi vogliamo concedere solo un click ogni tot ore.

Eventualmente, in un futuro, potrai rompere le scatole ai tuoi amici perché clicchino mentre tu non puoi, per ravvelocizzare la procedura.

Prima di mettere in ghiaccio il progetto avevo già imbastito il sistema per cui il click dell'utente viene salvato su DB. Purtroppo questo mi ha fatto entrare nella terribile palude dei timestamp.

L'ORM di perl (DBIX::Class) ha una sua astrazione dei timestamp (DateTime) che funziona bene, ma naturalmente non è come gestire un semplice numerillo. Fosse per me tutte le data/ora si conterebbero come secondi da epoch, ma in certe circostanze di arriva presto a scoprire che questo modo di pensare è abbastanza poco versatile.

Le cose che quindi ho implementato sono:

- Un check per controllare se l'utente ha a disposizione il click o no.

- Un sistema per misurare quanto manca dalla prossima opportunità di click

- Un Javascript (bhe, l'installazione di questo javascript) per la visualizzazione a frontend del countdown.

Il primo grosso problema contro cui mi sono scontrato è il fatto che recuperare il timestamp salvato su DB da bravo bambino, ovvero chiamando il controller che va su DBIX::Class e poi modificando il medesimo, questo rimaneva modificato in modo imperituro nella sessione apache. Attenzione! Il dato non si aggiornava lato DB, ma lato sistema continuava ad aggiornarsi per ogni add, con ovvi e notevoli effetti fastidiosi.

Sono uscito da questo scoglio solo facendo del timestamp un clone() che ovviamente ha creato un oggetto sganciato dall'informazione in mio possesso, permettendomi di manipolarlo come meglio credo.

Lo scoglio che al momento non ho ancora superato riguarda il fatto che DateTime::Duration è un po' cocciuto quando si tratta di fare conversioni.

Il mio ragionamento è: vediamo quanto tempo manca al prossimo click facendo (TIMESTAMP ULTIMO CLICK + X) - ORA. Dove X è il tempo che voglio l'utente attenda.

Questo, fatto coi DateTime, produce un DateTime::Duration, una hash con il risultato in anni, mesi, giorni, ore, minuti, secondi ecc ecc ecc.

Visto che parliamo di un ordine di grandezza che alla fine sarà in ore e visto che comunque il dettaglio mi va bene in secondi (che è più manipolabile) mi piacerebbe che Duration non mi restituisse una struttura così articolata, ma, appunto, l'ammontare in secondi del tempo che manca.

Peccato che la matematica sottesa a DateTime sia contorta e mostruosa e recuperare questo dato non è affatto semplice.

Se non trovo una soluzione reale dovrò ricorrere a un qualche escamotage. 

Musica nelle orecchie:  http://www.youtube.com/watch?v=SsB9DMF6gYw