Model.put() Override?
6 views
Skip to first unread message
Devel63
Jan 14, 2009, 12:45:42 AM1/14/09
to Google App Engine
I overrode the put method on a class derived from Model, primarily
because I wanted to do some accounting work when a new object was
saved (in the simplest case, just keeping track of a counter). It
does its work, then calls super.
It works fine.
Until I use db.put([ob1,obj2,obj3]) to save a bunch of these, and then
of course the individual object.put() functions are never called.
Is there a best practice for this? I really liked having it in the
"put", because then no caller needed to know about it, and it just
took care of itself. Is the best thing to precede every "put" call
with an explicit "put_prep" call?
because I wanted to do some accounting work when a new object was
saved (in the simplest case, just keeping track of a counter). It
does its work, then calls super.
It works fine.
Until I use db.put([ob1,obj2,obj3]) to save a bunch of these, and then
of course the individual object.put() functions are never called.
Is there a best practice for this? I really liked having it in the
"put", because then no caller needed to know about it, and it just
took care of itself. Is the best thing to precede every "put" call
with an explicit "put_prep" call?
boson
Jan 14, 2009, 3:22:31 PM1/14/09
to Google App Engine
That is a curious situation. I would like to know also if there is a
way to inject code into the put-stream regardless of method called, as
I have various put() overrides as well.
way to inject code into the put-stream regardless of method called, as
I have various put() overrides as well.
James Ashley
Jan 17, 2009, 2:15:37 PM1/17/09
to Google App Engine
The "simple" answer seems to be "override the db class." That's
totally off the top of my head, and it may be completely unrealistic.
Something like (totally untested and almost definitely wrong. Consider
it pseudo-code):
class my_db(google.ext.db):
def put(self, *objects, **kwargs):
for o in objects:
o.pre_put()
super(google.ext.db, self).put(*objects, **kwargs)
Then the models that were overriding put() could put that override
code in pre_put() instead (and change put() to just call that before
calling super().put()...).
You'd have to juggle the nuances of things like post_put(), and any
side-effects. But it seems like a reasonable compromise.
totally off the top of my head, and it may be completely unrealistic.
Something like (totally untested and almost definitely wrong. Consider
it pseudo-code):
class my_db(google.ext.db):
def put(self, *objects, **kwargs):
for o in objects:
o.pre_put()
super(google.ext.db, self).put(*objects, **kwargs)
Then the models that were overriding put() could put that override
code in pre_put() instead (and change put() to just call that before
calling super().put()...).
You'd have to juggle the nuances of things like post_put(), and any
side-effects. But it seems like a reasonable compromise.
Bill
Jan 21, 2009, 2:47:02 AM1/21/09
to Google App Engine
The most recent SDK (1.1.8) now allows hooks, and that seems to be the
best way to hack datastore puts. Jens (http://blog.appenginefan.com/)
has started to blog about use of the hook feature and gave two
examples at our local App Engine meetup tonight. Stay tuned to his
blog for a good explanation.
In the meantime, look at appengine.api.apiproxy_stub_map.py and you'll
see some hook methods. You can register methods to run pre- or post-
put.
If you supply a hook at this level of the API, you can use your hack
even when bypassing the Model API.
best way to hack datastore puts. Jens (http://blog.appenginefan.com/)
has started to blog about use of the hook feature and gave two
examples at our local App Engine meetup tonight. Stay tuned to his
blog for a good explanation.
In the meantime, look at appengine.api.apiproxy_stub_map.py and you'll
see some hook methods. You can register methods to run pre- or post-
put.
If you supply a hook at this level of the API, you can use your hack
even when bypassing the Model API.
Reply all
Reply to author
Forward
0 new messages