Re: [Python] ragionamento sul model

[Manlio Perillo]

Lawrence Oluyede ha scritto:

administrative_area è un termine generico che può gestire contee,
distretti, regioni, etc.


Boh preferisco termini più di uso comune, altrimenti ogni volta devo
andare a guardare il model :-P
Comunque per me è uguale su questo campo


E questo non è permesso? Devo vedere meglio.


fammi sapere



Non ho avuto il tempo di vedere meglio, ma la relazione OneToOne 
dovrebbe fare qualcosa del genere:


user_id INTEGER PRIMARY KEY REFERENCE user(user_id)

Quindi non ci dovrebbero essere problemi.



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

Re: [Python] ragionamento sul model

[Lawrence Oluyede]

Io mi terrei la possibilità di esportare, non di importare. Cosi
evitiamo di riempire il DB con informazioni useless o little useful.

hcard e geo non sono formati per il model, ma semplicemente
convenzioni per il template


--
Lawrence
http://www.oluyede.org/blog
http://www.neropercaso.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Lawrence Oluyede]

administrative_area è un termine generico che può gestire contee,
distretti, regioni, etc.


Boh preferisco termini più di uso comune, altrimenti ogni volta devo
andare a guardare il model :-P
Comunque per me è uguale su questo campo


E questo non è permesso? Devo vedere meglio.


fammi sapere



--
Lawrence
http://www.oluyede.org/blog
http://www.neropercaso.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Giovanni Porcari]

Il giorno 12/gen/07, alle ore 16:00, Manlio Perillo ha scritto:

L'idea di usare vcard, linearizzandolo per adattarlo al modello  
redazionale, è buona.


Però in questo modo è possible solo esportare i dati in formato  
vcard, non importarli (a meno che il documento non sia semplice).


Pensavo proprio all'import invece

G___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Manlio Perillo]

Giovanni Porcari ha scritto:


Non direi che vCard 'usa' un modello gerarchico ma piuttosto che la 
'realtà' di cui è il modello è gerarchica.




Si, direi che le  due frasi sono equivalenti.

Credo sia possibile creare in un database relazionale delle table che 
descrivano dati gerarchici senza per questo 'violentarlo'.


La proposta era solo quella di usare come nomi dei campi i nomi che si 
usano in vcard  creando le table necessarie.
Ovvero se esistono dei modi 'standard' di definire dei campi forse è 
inutile idearne di nuovi


Si tratta quindi di parsare la vcard e creare i records necessari.



L'idea di usare vcard, linearizzandolo per adattarlo al modello 
redazionale, è buona.


Però in questo modo è possible solo esportare i dati in formato vcard, 
non importarli (a meno che il documento non sia semplice).


Se gli altri sono daccordo, possiamo anche abbozzare qualcosa, ma 
abbiamo davvero bisogno di tutte quelle informazioni?


Per ora abbiamo una tabella per gli indirizzi.
Magari possiamo aggiungerne una con i recapiti telefonici, email, etc.




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

Re: [Python] ragionamento sul model

[Giovanni Porcari]

Non direi che vCard 'usa' un modello gerarchico ma piuttosto che la  
'realtà' di cui è il modello è gerarchica.


Credo sia possibile creare in un database relazionale delle table che  
descrivano dati gerarchici senza per questo 'violentarlo'.


La proposta era solo quella di usare come nomi dei campi i nomi che  
si usano in vcard  creando le table necessarie.
Ovvero se esistono dei modi 'standard' di definire dei campi forse è  
inutile idearne di nuovi


Si tratta quindi di parsare la vcard e creare i records necessari.

G.




Il giorno 12/gen/07, alle ore 15:33, Manlio Perillo ha scritto:


Giovanni Porcari ha scritto:

Il giorno 12/gen/07, alle ore 13:03, Manlio Perillo ha scritto:
La tabella Address contiene gli indirizzi in modo che si possano  
fare le ricerche via SQL.



Provo ad azzardare una 'fesseria' ...
Ogni pythonista 'dovrebbe' avere una vcard completa. Sarebbe  
quindi forse intelligente appoggiarsi al modello di vcard  
traducendolo nelle tabelle appropriate.
Un pulsante di upload della vcard potrebbe creare tutti i record  
necessari a descrivere l'indirizzo o gli indirizzi che si intende  
mettere online.


vCard usa un modello gerarchico.

Possiamo creare una tabella prendendo spunto da vCard (io ho fatto  
qualcosa di analogo per iCal), ma non credo sia fattibile prendere  
un documento vCard è gestirlo in un database relazionale, a meno di  
non "violentare" il database.




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



___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Manlio Perillo]

Lawrence Oluyede ha scritto:

- perchè non hai usato il wiki?


Perché volevo sapere se andava bene prima di metterlo la


- province_or_district non mi convince


è la cosa più umana che mi viene in mente. Negli stati uniti esistono
le contee, in cina i distretti, in italia le province. quel campo
potrebbe contenere "San Mateo" o "Bergamo, Lombardia" o "Ni hon"



Appunto.
administrative_area è un termine generico che può gestire contee, 
distretti, regioni, etc.



- GeoLocation al momento è 'legato' ad user. La cosa va vista meglio e
   dipende su quali tabelle andiamo poi a fare le query.


Si sicuramente


   Inoltre ForeignKey mi sembra crei una lista, io ho usato OneToOne.


E se due fratelli che convivono si aggiungono? Stessa geo location ma
due persone diverse.


E questo non è permesso? Devo vedere meglio.


Per questo non ho usato onetoone



Il problema è che Django vuole gestire tutto lui, con SQLALchemy era 
tutto più semplice... ;-).




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

Re: [Python] ragionamento sul model

[Manlio Perillo]

Giovanni Porcari ha scritto:


Il giorno 12/gen/07, alle ore 13:03, Manlio Perillo ha scritto:

La tabella Address contiene gli indirizzi in modo che si possano fare 
le ricerche via SQL.




Provo ad azzardare una 'fesseria' ...

Ogni pythonista 'dovrebbe' avere una vcard completa. Sarebbe quindi 
forse intelligente appoggiarsi al modello di vcard traducendolo nelle 
tabelle appropriate.
Un pulsante di upload della vcard potrebbe creare tutti i record 
necessari a descrivere l'indirizzo o gli indirizzi che si intende 
mettere online.


vCard usa un modello gerarchico.

Possiamo creare una tabella prendendo spunto da vCard (io ho fatto 
qualcosa di analogo per iCal), ma non credo sia fattibile prendere un 
documento vCard è gestirlo in un database relazionale, a meno di non 
"violentare" il database.




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

Re: [Python] ragionamento sul model

[Manlio Perillo]

Fredo Corleone ha scritto:



2007/1/12, Manlio Perillo <[EMAIL PROTECTED] 
>:


(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).


Potresti  spiegarmi  questa cosa ("non possibile in SQL puro")? Visto 
che da come

l'hai messa mi sembra possibilissimo, credo di non aver capito.
(Scusate per l'OT rispetto alla discussione)
Ciao!



La struttura dati per gestire un indirizzo è gerarchica.
Dai una occhiata allo standard OASIS xAL.

Una struttura gerarchica offre grande flessibilità, ma ovviamente non la 
puoi gestire con un modello relazionale.




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

Re: [Python] ragionamento sul model

[Lawrence Oluyede]

- perchè non hai usato il wiki?


Perché volevo sapere se andava bene prima di metterlo la


- province_or_district non mi convince


è la cosa più umana che mi viene in mente. Negli stati uniti esistono
le contee, in cina i distretti, in italia le province. quel campo
potrebbe contenere "San Mateo" o "Bergamo, Lombardia" o "Ni hon"


- GeoLocation al momento è 'legato' ad user. La cosa va vista meglio e
   dipende su quali tabelle andiamo poi a fare le query.


Si sicuramente


   Inoltre ForeignKey mi sembra crei una lista, io ho usato OneToOne.


E se due fratelli che convivono si aggiungono? Stessa geo location ma
due persone diverse.
Per questo non ho usato onetoone

--
Lawrence
http://www.oluyede.org/blog
http://www.neropercaso.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Manlio Perillo]

Lawrence Oluyede ha scritto:

Che ne dite?

http://dpaste.com/hold/4597/



Solo 3 note:
- perchè non hai usato il wiki?
- province_or_district non mi convince
- GeoLocation al momento è 'legato' ad user. La cosa va vista meglio e
  dipende su quali tabelle andiamo poi a fare le query.
  Inoltre ForeignKey mi sembra crei una lista, io ho usato OneToOne.



Saluti  Manlio Perillo

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Lawrence Oluyede]

controproposta.
http://microformats.org/wiki/hcard
e, ovviamente,
http://microformats.org/wiki/geo


Li implementi tu :-) ?

Comunque: http://trac.python.it/wiki/Progetti/Pythonisti/Idee

--
Lawrence
http://www.oluyede.org/blog
http://www.neropercaso.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Giovanni Porcari]

Il giorno 12/gen/07, alle ore 14:39, Carlo C8E Miron ha scritto:



controproposta.
http://microformats.org/wiki/hcard
e, ovviamente,
http://microformats.org/wiki/geo



Più che una controproposta mi pare la stessa proposta ...'arricchita'  
e migliorata.


D'accordissimo... ;)

G___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Giovanni Porcari]

Volendo poi la pappa fatta (compreso l'hosting gratuito)

http://www.google.com/base/help/about.html?hl=en_US

A volte Google mi irrita 


G
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Lawrence Oluyede]

Ogni pythonista 'dovrebbe' avere una vcard completa. Sarebbe quindi forse
intelligente appoggiarsi al modello di vcard traducendolo nelle tabelle
appropriate.
Un pulsante di upload della vcard potrebbe creare tutti i record necessari a
descrivere l'indirizzo o gli indirizzi che si intende mettere online.
Ovviamente si può mettere online un modulo per riempirla direttamente ma ci
sono molti software che generano la vcard e non mi pare urgentissimo.


Non è malvagia come idea, mi era stato suggerito anche
http://microformats.org/wiki/hcard e avevo pensato anche al supporto a
openid per l'identificazione

--
Lawrence
http://www.oluyede.org/blog
http://www.neropercaso.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Carlo C8E Miron]

On 1/12/07, Giovanni Porcari <[EMAIL PROTECTED]> wrote:

Il giorno 12/gen/07, alle ore 13:03, Manlio Perillo ha scritto:

La tabella Address contiene gli indirizzi in modo che si possano fare le
ricerche via SQL.

Ogni pythonista 'dovrebbe' avere una vcard completa. Sarebbe quindi forse
intelligente appoggiarsi al modello di vcard traducendolo nelle tabelle
appropriate.
Un pulsante di upload della vcard potrebbe creare tutti i record necessari a
descrivere l'indirizzo o gli indirizzi che si intende mettere online.
Ovviamente si può mettere online un modulo per riempirla direttamente ma ci
sono molti software che generano la vcard e non mi pare urgentissimo.


controproposta.
http://microformats.org/wiki/hcard
e, ovviamente,
http://microformats.org/wiki/geo

(c)

--
Carlo C8E Miron, ICQ #26429731
--
Disclaimer:
If I receive a message from you, you are agreeing that:
1. I am by definition, "the intended recipient".
2. All information in the email is mine to do with as I see fit and
make such financial profit, political mileage, or good joke as it
lends itself to. In particular, I may quote it on USENET or the WWW.
3. I may take the contents as representing the views of your company.
4. This overrides any disclaimer or statement of confidentiality that
may be included on your message.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Giovanni Porcari]

Il giorno 12/gen/07, alle ore 13:03, Manlio Perillo ha scritto:

La tabella Address contiene gli indirizzi in modo che si possano  
fare le ricerche via SQL.


Provo ad azzardare una 'fesseria' ...

Ogni pythonista 'dovrebbe' avere una vcard completa. Sarebbe quindi  
forse intelligente appoggiarsi al modello di vcard traducendolo nelle  
tabelle appropriate.
Un pulsante di upload della vcard potrebbe creare tutti i record  
necessari a descrivere l'indirizzo o gli indirizzi che si intende  
mettere online.
Ovviamente si può mettere online un modulo per riempirla direttamente  
ma ci sono molti software che generano la vcard e non mi pare  
urgentissimo.




G.___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Lawrence Oluyede]

Che ne dite?

http://dpaste.com/hold/4597/
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Lawrence Oluyede]

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


Certo


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


Possiamo mettere il tutto in un file di testo sotto svn volendo


--
Lawrence
http://www.oluyede.org/blog
http://www.neropercaso.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Fredo Corleone]

2007/1/12, Manlio Perillo <[EMAIL PROTECTED]>:


(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).



Potresti  spiegarmi  questa cosa ("non possibile in SQL puro")? Visto che da
come
l'hai messa mi sembra possibilissimo, credo di non aver capito.
(Scusate per l'OT rispetto alla discussione)
Ciao!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [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
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Lawrence Oluyede]

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)

- 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.

- 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)

Io scarterei la 1.

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

--
Lawrence
http://www.oluyede.org/blog
http://www.neropercaso.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] ragionamento sul model

[Manlio Perillo]

Lawrence Oluyede ha scritto:

Sto ragionando sul model di geo e il profilo e non mi convince molto.

L'utente arriva sul sito, si iscrive e inserisce i suoi dati:

nome, cognome
via, città, eventuale provincia, nazione

preme "submit" e geo entra in gioco macinando l'indirizzo e
trasformandolo in una geo-location,
poi questa geo-location viene associata ad uno User.

Giusto?



Si.


Quindi la mia domanda è: ci serve davvero il model per memorizzare gli
indirizzi? Tanto possiamo ricavarli da geo-location (e poi
sinceramente non ci servono, c'è la mappa apposta).



Sono cose leggermente diverse.
geo si occupa di indirizzi 'raw', dati direttamente in pasto al geocoder.

In particolare GeoLocation contiene:
- indirizzo così come immesso dall'utente
  (o costruito dal modulo profile a partire da country, locality, etc)
- indirizzo formattato da Google
- dettaglio indirizzo, in JSON nel formato xAL.


La tabella Address contiene gli indirizzi in modo che si possano fare le 
ricerche via SQL.


Certo, nulla ci vieta di tenere solo l'address_detail di GeoLocation e 
farci le ricerche custom sopra (usando una funzione in plpythonu tipo:

 data['AddressDetail']['Locality'] == 'Roma'
).

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).



Magari mi sono spiegato, magari no... però con questo genere di
brainstorming almeno abbiamo tutti le idee chiare (e coerenti)




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