[Python] impressioni su Django

[Manlio Perillo]

Sandro Dentella ha scritto:
>>>> Per fortuna ti permette di definire le primary key come vuoi tu (ma non
>>>> di default, in cui vengono usate primary key surrogate).
>>> anche sqlalchemy tende a farti usare primary key surrogate, dico questo in
>>> quanto considera la PK come non modificabile. Lavoro con sqlalchemy da
>>> febbraio ed ho dovuto rivedere un po' la struttura dei miei db per poterla 
>>> adattare a  sqlalchemy anche se è molto ben fatto.
>>>
>> Davvero?
>> Nella documentazione non vi è menzione di questa particolarità.
>>
>> Probabilmente è una difesa preventiva contro database come MySQL e
>> SQLite che non supportano l'integrità referenziale (e quindi se cambi
>> una primary key, tutte le foreign key collegate diventano prive di
>> significato).
>>
>> Segnalalo come bug, credo che le primary key debbano essere modificabili
>> per i database dove ha senso.
> 
> la sua risposta è stata:
> 
>    you generally shouldnt store any "information" in a primary key.  primary
>    keys are by definition immutable so SA would likely trip up if you change
>    them.  its conceivable that a feature could be added to allow updating the
>    primary key columns but it would add a lot of complexity to the saving
>    mechanism, to support a pattern that generally is not really correct.
> 
>    http://en.wikipedia.org/wiki/Primary_key
> 
> 
>    if you want an extra "check for this condition" step its not totally
>    impossible, although i dont know if I want to add assertions throughout
>    the code for things like this since it will eventually chunk down the
>    performance.  feel free to add a ticket to Trac for a "check that primary
>    key columns havent changed, raise exception" feature, id have to consider
>    how non-intrusive that is.
> 

Ti ha risposto velocemente!

Comunque riguardo al "pattern that generally is not really correct" ho
qualche dubbio.

A che servirebbero altrimenti i vincoli di integrità referenziale?
Dire che la primary key non dovrebbe immagazzinare nessuna informazione
porta a diversi problemi (c'è stata una discussione a riguardo anche in
it.comp.software.database).


> L'utima parte si riferisce al fatto che ignora semplicemente senza sollevare
> errori. Ora solleva errore solo se contemporaneamente campi PK *E* fai
> altro:
> 
> [...]
> 

Almeno un log di warning dovrebbe darlo...

> 
>> A proposito: nella costruzione di una foreign key sono previste le
>> clausole on update/on delete, (not) deferrable, initially
>> immediate/deferred?
> 
> mi pare che siano state recentemente inserite (in SA, nonso in Django)
> 

Django non credo lo farà mai ;-).

>> E' possibile creare indici parziali con PostgreSQL?
> ovvero?
> 
>

CREATE INDEX access_log_client_ip_ix ON access_log (client_ip)
    WHERE NOT (client_ip > inet '192.168.100.0' AND client_ip < inet
'192.168.100.255');

In pratica crea l'indice solo dove decidi tu.
Non che le abbia mai usate.

Sono solo curioso di sapere quanto sqlalchemy è flessibile per adattarsi
alle feature dei vari database (per non parlare della gestione delle
transazioni).

Sono convinto che l'idea di avere una implementazione unica per diversi
database è una illusione, e funziona solo se si usa il database ai
minimi termini (ma spesso, in effetti, è così nell'85% dei casi credo).



Saluti  Manlio Perillo