Changes between Version 19 and Version 20 of NoSqlSupport


Ignore:
Timestamp:
Jun 30, 2011, 3:17:43 PM (13 years ago)
Author:
Jonas H.
Comment:

patch links

Legend:

Unmodified
Added
Removed
Modified
  • NoSqlSupport

    v19 v20  
    4545= select_related() =
    4646
     47[https://code.djangoproject.com/attachment/ticket/16385/0ad3af376503d32dab0adb8c9aaa57bd389ea0b2.diff Patch]
     48
    4749 Problem:: Django's internal representation of `select_related()` depends on JOINs, which aren't supported on NoSQL DBs.
    4850
     
    5254
    5355= !AutoField =
     56
     57[https://code.djangoproject.com/attachment/ticket/16385/043f2c08b87dda585d40a1ab225106543909f4a6.diff Patch]
    5458
    5559 Problem:: Currently, `AutoField` assumes that it's always an integer. However, in several NoSQL DBs (MongoDB, SimpleDB, etc.) the primary key is a string.
     
    6468
    6569= INSERT vs UPDATE =
     70
     71[https://code.djangoproject.com/attachment/ticket/16385/2885579c6f8a2f41422788b0abdee3da816144f8.diff Patch]
    6672
    6773 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.
     
    150156= Auth password reset URLs =
    151157
    152 #14881, [http://code.djangoproject.com/attachment/ticket/14881/django-auth-string-pk-support.patch Patch]
     158#14881, [https://code.djangoproject.com/attachment/ticket/16385/c9f97bd7397a39ebcb9f8831b28d5ab3b4e57038.diff Patch]
    153159
    154160 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).
     
    160166= Minor issues =
    161167
    162 The default ordering on permissions requires JOINs. This makes them unusable on NoSQL DBs.
     168The 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])
    163169
    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).
     170The 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]
Back to Top