NDB users: Renaming @context.toplevel to @tasklets.toplevel; please use @ndb.toplevel!
Guido van Rossum
ndb/context.py. (Almost every line references the tasklets module. :-)
Therefore I'd like to move it to tasklets.py. Now, I know lots of
people probably have code that uses @context.toplevel. I'd like to
break such code in the next NDB release and in the next SDK, because
this may be one of the last chances I have to make incompatible API
changes.
So, if you don't want your code to break with the new version, please
switch to using @ndb.toplevel *NOW*!
In fact, in general you should be using "import ndb" instead of "from
ndb import model, tasklets, context, query", and you should use the
ndb prefix instead of its submodules. So, ndb.Model,
ndb.StringProperty, ndb.OR, etc. Also please stop using FilterNode --
use GenericProperty('name') == <expr> instead of FilterNode('name',
'=', <expr>).
--
--Guido van Rossum (python.org/~guido)
Guido van Rossum
> Thank You for the info!
>
> can i still use like this?
>
> application = ndb.toplevel(application.__call__)
Yes, that still works. (There's even an example of this in demo/main.py.)
Sudhir
production :-/
Guess I should pay more attention to the mailing list.
Sudhir
On Feb 11, 1:20 am, Guido van Rossum <gu...@google.com> wrote:
Guido van Rossum
try to minimize backward incompatible disruptions like this, but
there's one more coming up for the next SDK release (in about a
month): transactional semantics. This affects using transaction() and
get_or_insert() inside an existing transaction (as well as their async
counterparts). In NDB 0.9.8 (currently in the SDK), these will create
new, independent transactions, which we've found out is actually not a
good idea. So for NDB 0.9.9 (and already in the NDB repo) we'll change
these as follows:
- transaction() inside a transaction will raise an error
- get_or_insert() inside a transaction will run in that same transaction
If no transaction exists when either of these are called, the behavior
is the same.
If you must create multiple transactions, you can start them
simultaneously using the async API, or use the Context's transaction()
method (which is also async).
I'll send another reminder about this closer to the transition date.
--Guido
Sudhir Jonathan
Peter Retief
be queued maybe?
strange question, would it be possible to use NDB in a java controller
environment?
P
Guido van Rossum
> Sounds good… might also make sense to run this on it's own thread.
Will do, closer to the next switch.
> A transition date would also be really helpful, though. It's great the the
> API is constantly improving, but saying "make the switch NOW" doesn't have
> quite the same psychological effect as a headline saying "Breaking change
> happening on 24th(?) February". I don't even think the exact date is needed:
> a date a few days earlier should work just fine.
Good point. In general though, our release schedule is pretty
predictable (every 4 weeks) and new runtimes are always pushed out a
few days before the new SDK is announced.
>> these will create
>> new, independent transactions, which we've found out is actually not a
>> good idea.
>
>>If you must create multiple transactions, you can start them
>> simultaneously using the async API, or use the Context's transaction()
>
> I'm guessing the point is that it's a bad idea to start multiple
> transactions are different times, but starting them simultaneously should be
> okay?
That's a slight simplification, but comes close to the point:
*outside* a transaction, when you start a transaction and wait for it
to finish, the results of the transaction will be available to you
immediately. But *inside* a transaction, when you run an *independent*
transaction, the results of the latter will not be available to you --
your *current* transaction will continue to see the world as it was
when *it* started.
--Guido