Changes between Version 2 and Version 3 of NonSqlBackends

Timestamp:

Aug 12, 2009, 3:48:11 AM (15 years ago)

Author:

Waldemar Kornewald

Comment:

--

NonSqlBackends

@@ -1 @@
-Here we collect the refactorings required for non-sql (or non-relational) backends.
+Here we collect the high-level refactorings required for non-sql (or non-relational) backends. Also see the specific backend docs for details: AppEngine
 
 = sql.subqueries =
@@ -9 +9 @@
 TODO: 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).
 
-= Model = 
+= Model =
 
 == Multi-table inheritance ==
@@ -17 +17 @@
 == save_base() ==
 
-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.
+The 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.
 
 == delete() ==
 
-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.
+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).
 
 = Transactions =
 
 Not 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).
-
-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.
 
 = Queries =