This repository has been archived by the owner on Sep 2, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 38
afterInit called twice + errors in it not caught (breaks compat.) #34
Comments
erikkaplun
pushed a commit
to erikkaplun/twistar
that referenced
this issue
Nov 19, 2012
…ot being caught when constructing a new model instance; refs bmuller#30; fixes bmuller#34
erikkaplun
pushed a commit
to erikkaplun/twistar
that referenced
this issue
Nov 19, 2012
…ot being caught when constructing a new model instance; refs bmuller#30; fixes bmuller#34
(Ignore the first reference—I |
erikkaplun
pushed a commit
to erikkaplun/twistar
that referenced
this issue
Nov 19, 2012
…turns a Deferredl; refs bmuller#34 This does not ensure backwards compabitility--previously since afterInit was not called during instantiation, instantiation was never deferred--but sure does improve it by providing it in cases where afterInit is not deferred.
The last commit provides backwards compatibility in most cases (i.e. when |
erikkaplun
pushed a commit
to erikkaplun/twistar
that referenced
this issue
Nov 19, 2012
erikkaplun
pushed a commit
to erikkaplun/twistar
that referenced
this issue
Nov 19, 2012
…ull control over how __init__ is called; refs bmuller#34
erikkaplun
pushed a commit
to erikkaplun/twistar
that referenced
this issue
Nov 30, 2012
…ot being caught when constructing a new model instance; refs bmuller#30; fixes bmuller#34
erikkaplun
pushed a commit
to erikkaplun/twistar
that referenced
this issue
Nov 30, 2012
…turns a Deferredl; refs bmuller#34 This does not ensure backwards compabitility--previously since afterInit was not called during instantiation, instantiation was never deferred--but sure does improve it by providing it in cases where afterInit is not deferred.
erikkaplun
pushed a commit
to erikkaplun/twistar
that referenced
this issue
Nov 30, 2012
erikkaplun
pushed a commit
to erikkaplun/twistar
that referenced
this issue
Nov 30, 2012
…ull control over how __init__ is called; refs bmuller#34
erikkaplun
pushed a commit
to erikkaplun/twistar
that referenced
this issue
Nov 30, 2012
…ot being caught when constructing a new model instance; refs bmuller#30; fixes bmuller#34
erikkaplun
pushed a commit
to erikkaplun/twistar
that referenced
this issue
Nov 30, 2012
…turns a Deferredl; refs bmuller#34 This does not ensure backwards compabitility--previously since afterInit was not called during instantiation, instantiation was never deferred--but sure does improve it by providing it in cases where afterInit is not deferred.
erikkaplun
pushed a commit
to erikkaplun/twistar
that referenced
this issue
Nov 30, 2012
erikkaplun
pushed a commit
to erikkaplun/twistar
that referenced
this issue
Nov 30, 2012
…ull control over how __init__ is called; refs bmuller#34
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
(I will describe both the issue and the solution here because I already have a patch for this)
After I added a call to
afterInit
inDBObject.__init__
, it (now obviously) started to be called twice: once percreateinstances
and once per__init__
. So I wanted to remove the call toafterInit
increateInstances
. Seeing the code increateInstances
though made me realise that my added line in__init__
swallows errors inafterInit
. ButafterInit
needs to be asynchronous (if not for any practical pruposes—but there are—as per the doc, at least), which means it cannot really be called from__init__
because__init__
is not allowed to return anything (and thus not allowed to return aDeferred
). However,__new__
does not suffer from this limitation. So the end solution is to put the call toafterInit
intoDBObject.__new__
.As a bonus, I also updated the usage of
DeferredList
increateInstances
to includefireOnFirstErrback=True, consumeErrors=True
so that any exceptions wouldn't go unnoticed.The text was updated successfully, but these errors were encountered: