[Python] impressioni su Django

[Manlio Perillo]

Sandro Dentella ha scritto:
>> Si, hai ragione.
>> Un join implicito.
>> Il problema è che Django cerca di usare il database nei minimi termini,
>> usandolo come lo userebbe un programmatore e non un esperto di database
>> relazionali.
> 
> vero se intendi che ad esempio non ha supporto per trigger, stored procedure
> ett, etc. Vero è che per molti siti non servono e che le cose "serie"
> secondo me è meglio non farle con il web ma con interfacce alla Gtk/Wx.
> In ogni caso condjango puoi sempre passare all'SQL puro e tutto funziona
> a meraviglia.
> 

Si, puoi sempre scrivere codice a mano.

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

A proposito: nella costruzione di una foreign key sono previste le
clausole on update/on delete, (not) deferrable, initially
immediate/deferred?

E' possibile creare indici parziali con PostgreSQL?

>> Io per ora scrivo tutte le query a mano, usando delle interfacce per
>> l'accesso al database.
>>
>> Il vantaggio è che aggiungo un livello di astrazione dal database (il
>> database ed il codice Python vivono su due piani diversi).
>>
>> Però sono costretto a definire delle interfacce limitate (non posso
>> prevedere tutto e diventerebbe troppo complesso da mantenere).
> 
> Sono curioso di capire meglio. Da un anno lavoro ad una libreria GTK di accesso
> al db che renderò GPL non appena avrò il tempo di scrivere un po' di
> documentazione... uso sqlalchemy quindi funziona per molti backend
> differenti.
> 


Ad esempio per una gestione di utenti:

class IUser(Interface):
  def getUserList():
     pass

  def addUser(user_name, password)
     pass


e poi l'implementazione per ciascun database

class SQLUser(Adapter):
   def getUserList(self):
      query = "SELECT user FROM Users"
      return ...

   ...



L'adapter viene registrato sull'ogetto connessione (in particolare
l'interfaccia IStore).

Quindi faccio, ad esempio:

conn = store.Store(":memory:")
users = IUser(conn)


Anche la classe Store è implementata per ogni database.
Uso le zope interfaces.



Saluti  Manlio Perillo