2010-08-10 10 views

risposta

4

no. Funzionerà bene.

+0

Grazie mille :) – mauzepeda

+1

Puoi citare qualsiasi documentazione SQLAlchemy che suggerisce che questo sarebbe ok? – DuneBug

+1

@DuneBug Non riesco a capire perché sarebbe un problema. Lo stesso Sqlalchemy non sovrascrive quei metodi speciali per la base dichiarativa. – nosklo

2

Forse, a seconda dell'implementazione della funzione di confronto.

dovete fare attenzione quando si usano __eq__ o __cmp__ per il confronto con l'oggetto other, perché SQLAlchemy può confrontare il vostro oggetto con alcuni simboli come NEVER_SET che non hanno lo stesso tipo. Date un'occhiata a questo metodo SQLAlchemy:

def get_all_pending(self, state, dict_): 
    if self.key in dict_: 
     current = dict_[self.key] 
     if current is not None: 
      ret = [(instance_state(current), current)] 
     else: 
      ret = [(None, None)] 

     if self.key in state.committed_state: 
      original = state.committed_state[self.key] 
      if original not in (NEVER_SET, PASSIVE_NO_RESULT, None) and \ 
       original is not current: 

       ret.append((instance_state(original), original)) 
     return ret 
    else: 
     return [] 

La linea original not in (NEVER_SET, PASSIVE_NO_RESULT, None) può sollevare un errore se il confronto non verifica l'uguaglianza dei tipi di prima, o per l'esistenza dei campi che vengono utilizzati nel confronto

Come soluzione, è necessario tenere conto di diversi tipi.

Evitare inoltre di ignorare __cmp__ e utilizzare rich comparison operators instead.

+0

Buona cattura! Questo è importante. –

Problemi correlati