Code

Changes between Version 10 and Version 11 of AppEngine


Ignore:
Timestamp:
02/25/09 04:19:16 (5 years ago)
Author:
wkornewald
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AppEngine

    v10 v11  
    5353The pk property should return an url-safe string that contains the key_name without the safety prefix (i.e., the value of the !CharField(primary_key=True)) and the parent pk. This is more portable than using the str(Key) because it doesn't contain the model and app name. Moreover, in case you specified a pk manually , the URLs will be much nicer. Even if you don't specify a key_name the URL is still shorter than the str(Key) version. 
    5454 
    55 In order to optimize code it's useful to be able to get the pk value of a !ForeignKey without dereferencing its entity. 
    56  
    5755Queries should support ancestor conditions. 
    5856 
     
    7876 
    7977Since JOINs don't work, Django should fall back to client-side JOIN emulation by issuing multiple queries. Of course, this only works with small datasets and it's inefficient, but that can be documented. It can still be a useful feature. 
    80  
    81 For efficiency it should be possible to retrieve only the pk values of a !ForeignKey or !ManyToManyField without loading the actual entities from the db. 
    8278 
    8379Many-to-many relations could be emulated with a !ListProperty(db.Key), so you can at least issue simple queries, but this can quickly hit the 5000 index entries limit. The alternative of having an intermediate table is useless if you have to issue queries on the data and due to the query limit you wouldn't be able to retrieve more than 1000 related entities, anyway (well, that could be worked around with __key__-based sorting, but then you have to create an index and you might hit CPU limits if you check a lot of data in one request).