[Python] ragionamento sul model

[Manlio Perillo]

Lawrence Oluyede ha scritto:
>> Ma non vorrei dipendere troppo da Google, e vorrei tenermi stretto al
>> modello relazionale (anche se le query 'object oriented' le possiamo
>> inserire come feature aggiuntiva, ad esempio posso cercare i pythonisti
>> che abitano nella mia stessa via, cosa non possibile in SQL puro).
> 
> Ho appena ragionato con Carlo e quello che n'è uscito è:
> 
> - l'utente si registra, se google è down per qualhce motivo gli viene
> creato il profilo con i suoi dati e il campo address con l'indirizzo
> immesso da lui ma senza geolocation (bisogna associare il model
> geolocation al model profile ovviamente con una foreign key)
> 

Sia geolocation che profile sono legati alla tabella user.
Dato che usiamo Django appoggiamoci alla tabella predefinita per gli utenti.

> - l'utente si registra, google è up ma google sbaglia a trovare
> l'indirizzo allorché l'utente va nel suo profilo, fa edit e nel campo
> libero address magari specifica più informazioni finché google non
> trova le coordinate esatte.
> 

Se Google non trova l'indirizzo significa:
1) I dati sono sbagliati
2) Il codice che formatta l'indirizzo a partire dalle sue parti è errato
3) L'indirizzo non esiste

Non vedo la necessità di lasciare un campo di testo libero.

> - l'utente si registra, google è up ma non trova l'indirizzo, vedi sopra.
> 
> Soluzione 1: l'indirizzo è semplicemente un TextField "via, città,
> nazione" e usiamo LIKE per girarci dentro
> Soluzione 2: l'indirizzo è tipo quello che hai fatto te (leggermente
> più umano e semplificato)
> 

Bisogna trovare una soluzione che vada bene per tutte le nazioni e che 
si flessibile.
Ci serve la consulenza di chi conosce altri paesi.

> Io scarterei la 1.
> 

Anche io, non si possono fare ricerche mirate.
L'unico dubbio, casomai, è se usare una tabella separata per gli 
indirizzi o mettere tutto in profiles.

> Appena finisco il model lo metto sul wiki e posto il link
> 

Mettilo sotto la directory Projects/Pythonisti/Features/.

P.S.
peccato che Trac non usi come backend Subversion, così si poteva 
inserire il testo delle pagine direttamente nel repository, via HTTP è 
stupidamente inefficiente.





Saluti  Manlio Perillo