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