Lawrence Oluyede ha scritto:
Si, questo lo avevo capito.
Stavo pensando a come gestirlo al meglio.

In stiq è cosi: c'è una relazione many to many tra news e tag (nel
nostro caso tra userprofile e tag). Django crea in automatico la
tabella di mezzo. Nel caso della UI poi ci pensiamo.

Invece io vorrei un campo che, per l'Italia, significhi regione.

administrative_area, l'ho messo apposta :-)


Ok.
Io avevo messo sub_administrative_area per la provincia e locality al posto di city.

Nel tuo caso la city indica il paese?
Quindi se io volessi cercare tutti i Pythonisti di Avellino non potrei farlo.

Comunque il problema è cercare di avere una idea di quanti campi servano per un indirizzo internazionale.

Poi li possiamo anche chiamare address_level_0, address_level_1 ;-).

Tutti i campi (eccetto country) possono essere nulli.

Anche la città?


Direi di si.
Quello che avevo pensato originariamente (nel caso Italia) era che io potessi indicare:
- Regione
- Provincia
- Comune
- Indirizzo

Tutti opzionali.


Ma con una foreign key mi sembra che l'attributo diventi una lista.

Certo ma finché Django non sistemerà sta cosa non vedo modi più
facili. Sarà una lista di un elemento 8-) Nel DB non è sto gran
problema, ci sarà una referenza tra le due tabelle e basta.


Ok allora.

Serve, dato che username *è* la primary key di quella tabella (ogni
utente ha una sola locazione).

Ovviamente se si toglie va cambiata sta cosa. Non ha senso rendere
conscia la geolocazione del concetto di utente. Questo intendevo con
il cambiamento.


Si, ma se si toglie la relazione con username, il modolu geo, così come è ora, non funziona più autonomamente, ma ha bisogno del modulo profile.

Altrimenti si usa una primary key farlocca, facciamo come dici tu, e
magari lasciamo aperta la possibilità che una persona abbia più di una
locazione (ad esempio casa/lavoro, ma in questo caso andrebbe aggiunto
un campo ulteriore per stabilire il tipo di indirizzo).

No beh, cosi poi tutti risultano con 2 duplicati e nemmeno la bandiera
degli USA è grande abbastanza per contenere tutti i Pythonisti :-)
Concordo sulla primary key farlocca.


Quanti pythonisti hanno un indirizzo di casa ed uno di lavoro? :-)

A quanto sembra molti di noi lavorano come consulenti/liberi professionisti (è l'unico modo per poter usare gli strumenti che vogliamo).


Non possiamo legare la geolocation allo username proprio perché
sinceramente vorrei usare l'email come username.

Allora non si usa proprio la tabella User e vanno cambiate un pò di cose.

Siamo sicuri?

Credo sia abbastanza
inutile generare uno username per un sito in cui la gente non deve
fare community, si iscrive e basta. Ogni tanto modifica il suo
profilo, ma la maggior parte dell'uso è da "anonymous user"


Non ti seguo.
Se ti registri con username non sei anonimo.
Che poi l'username sia la email cambia poco
(ma probabilmente significa non poter usare la gestione utenti di Django).


Tra l'altro, con il file formattato come nel mio esempio, possiamo
usare il comando COPY.

Ho già un file countries.sql con tutti gli insert del caso.


Non ne hai uno in semplice CSV?



Saluti  Manlio Perillo
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Rispondere a