Changes between Version 19 and Version 20 of NoSqlSupport
- Timestamp:
- Jun 30, 2011, 3:17:43 PM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
NoSqlSupport
v19 v20 45 45 = select_related() = 46 46 47 [https://code.djangoproject.com/attachment/ticket/16385/0ad3af376503d32dab0adb8c9aaa57bd389ea0b2.diff Patch] 48 47 49 Problem:: Django's internal representation of `select_related()` depends on JOINs, which aren't supported on NoSQL DBs. 48 50 … … 52 54 53 55 = !AutoField = 56 57 [https://code.djangoproject.com/attachment/ticket/16385/043f2c08b87dda585d40a1ab225106543909f4a6.diff Patch] 54 58 55 59 Problem:: Currently, `AutoField` assumes that it's always an integer. However, in several NoSQL DBs (MongoDB, SimpleDB, etc.) the primary key is a string. … … 64 68 65 69 = INSERT vs UPDATE = 70 71 [https://code.djangoproject.com/attachment/ticket/16385/2885579c6f8a2f41422788b0abdee3da816144f8.diff Patch] 66 72 67 73 Problem:: Currently, `Model.save_base()` runs a check whether the pk already exists in the database. This check is necessary for SQL, but it's unnecessary and inefficient on many NoSQL DBs which have an "upsert" operation that inserts or overwrites the entry in the DB. App Engine also doesn't allow to run queries within (optimistic) transactions, so the current `save()` method doesn't work on App Engine. … … 150 156 = Auth password reset URLs = 151 157 152 #14881, [http ://code.djangoproject.com/attachment/ticket/14881/django-auth-string-pk-support.patchPatch]158 #14881, [https://code.djangoproject.com/attachment/ticket/16385/c9f97bd7397a39ebcb9f8831b28d5ab3b4e57038.diff Patch] 153 159 154 160 Problem:: `django.contrib.auth`'s password reset URLs contain a base36-encoded user ID (`/reset/<user-id>/<token>/`). Several NoSQL backends (MongoDB, SimpleDB, etc.) use string-based primary keys. The password reset feature breaks if the user ID (the primary key) is not an integer (because base36 can only express integers). … … 160 166 = Minor issues = 161 167 162 The default ordering on permissions requires JOINs. This makes them unusable on NoSQL DBs. 168 The default ordering on permissions requires JOINs. This makes them unusable on NoSQL DBs. ([https://code.djangoproject.com/attachment/ticket/16385/0951738c5693be6a64c88e09f2dcf06499496465.diff How Django-nonrel fixes this]) 163 169 164 The permission creation code uses an `__in` lookup with too many values. App Engine can only handle 30 values (except for the primary key which can handle 500). This could be worked around, but the limitation was added for efficiency reasons (`__in` lookups are converted into a set of queries that are executed in parallel and then de-duplicated). Thus, it's not really a solution to just run multiple of those queries. Instead, the permission creation code should just fetch all permissions at once. Maybe in a later App Engine release this limitation will be removed when App Engine's new query mechanism goes live (which supports `OR` queries and gets rid of several other limitations). 170 The permission creation code uses an `__in` lookup with too many values. App Engine can only handle 30 values (except for the primary key which can handle 500). This could be worked around, but the limitation was added for efficiency reasons (`__in` lookups are converted into a set of queries that are executed in parallel and then de-duplicated). Thus, it's not really a solution to just run multiple of those queries. Instead, the permission creation code should just fetch all permissions at once. Maybe in a later App Engine release this limitation will be removed when App Engine's new query mechanism goes live (which supports `OR` queries and gets rid of several other limitations). [https://code.djangoproject.com/attachment/ticket/16385/e9cb952ff9052caa223dfa90529d869c00108674.diff Patch]