From 35c3d273bbf1bd8c9c41ac1c3d91f150df0eb280 Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Thu, 18 Aug 2011 11:38:40 +0200 Subject: Fix custom recursive loading in post_load callback Before we called the callback while holding the statements locked. As a result, if the callback tried to load another object of this type, it failed. Now we unlock the statements (since we have completely loaded the object from ODB's point of view) and then call the callback. The callback test has been updated to test this situation. --- odb/sqlite/object-statements.txx | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) (limited to 'odb/sqlite/object-statements.txx') diff --git a/odb/sqlite/object-statements.txx b/odb/sqlite/object-statements.txx index 0ae9886..9cd8344 100644 --- a/odb/sqlite/object-statements.txx +++ b/odb/sqlite/object-statements.txx @@ -70,7 +70,18 @@ namespace odb if (!delayed_.empty ()) load_delayed_ (); - object_traits::callback (db, *l.obj, callback_event::post_load); + // Temporarily unlock the statement for the post_load call so that + // it can load objects of this type recursively. This is safe to do + // because we have completely loaded the current object. Also the + // delayed_ list is clear before the unlock and should be clear on + // re-lock (since a callback can only call public API functions + // which will make sure all the delayed loads are processed before + // returning). + // + { + auto_unlock u (*this); + object_traits::callback (db, *l.obj, callback_event::post_load); + } g.release (); } -- cgit v1.1