Code

Changes between Version 2 and Version 3 of NonSqlBackends


Ignore:
Timestamp:
08/12/09 01:48:11 (5 years ago)
Author:
wkornewald
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NonSqlBackends

    v2 v3  
    1 Here we collect the refactorings required for non-sql (or non-relational) backends. 
     1Here we collect the high-level refactorings required for non-sql (or non-relational) backends. Also see the specific backend docs for details: AppEngine 
    22 
    33= sql.subqueries = 
     
    99TODO: Check if there is any SQL-related code that needs to be more abstract (as_sql() appears in a few places, but maybe it doesn't affect the port). 
    1010 
    11 = Model =  
     11= Model = 
    1212 
    1313== Multi-table inheritance == 
     
    1717== save_base() == 
    1818 
    19 The distinction between insert and update should be done by sql.Query. The check whether the pk already exists (which is part of the distinction) should be moved out, too. 
     19The distinction between insert and update should be done by sql.Query because not all backends make that distinction, at all. The check whether the pk already exists (which is part of the distinction) should be moved out, too. 
    2020 
    2121== delete() == 
    2222 
    23 model.delete() collects all referenced objects using _collect_sub_objects(). For non-sql backends this is not always possible for example when running in a transaction on app engine (only entities in the same entity group can be fetched from the datastore). Additionally delete() calls delete_objects() which makes use of DeleteQuery and UpdateQuery imported from sql.subqueries. There should be a way to override these query classes. 
     23model.delete() collects all referenced objects using _collect_sub_objects(). For non-sql backends this is not always possible, for example, when running in a transaction on App Engine (only entities in the same entity group can be fetched from the datastore). 
    2424 
    2525= Transactions = 
    2626 
    2727Not all backends support transactions, at all (e.g., SimpleDB). Some (e.g., App Engine) only support transactions similar to "SELECT ... FOR UPDATE" (which isn't exactly the same as @commit_on_success because it really locks items for read/write access). Not all backends support a BEGIN/END TRANSACTION operation, but only provide an interface for calling a function transactionally (like the @commit_on_success decorator). 
    28  
    29 Since on App Engine locking transactions can't access rows outside of the current entity group the post_save/_delete signal handlers aren't sufficient (though, sometimes they're exactly what you need). We really need signals for getting notified of "save" and "delete" after a locking transaction has finished. 
    3028 
    3129= Queries =