Changes between Version 10 and Version 11 of AppEngine
- Timestamp:
- Feb 25, 2009, 6:19:16 AM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
AppEngine
v10 v11 53 53 The 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. 54 54 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 57 55 Queries should support ancestor conditions. 58 56 … … 78 76 79 77 Since 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.82 78 83 79 Many-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).