Hi, You seem to found kind of an issue which happens with GeoDjango part as well. Most of the geodjango operations require quite heavy to/from data mangling while reading and/or writing data.
Currently there isn't clean solution to tell (per field) how data should be treated per backend. Django ORM works pretty well for a primitives like numbers, strings and such but when it goes to complex datatypes (like your encrypted field). It would be really useful to have something to allow data mangling on a when reading/writing data from/to database per backend basis. Unfortunately such a feature isn't easy to implement due the current way how ORM works. If you require such a functionality now, you should take a look how different GeoDjango backends deal with the similiar problem. On Thu, 1 Aug 2013 21:23:40 -0700 (PDT) Alejandro Dubrovsky <[email protected]> wrote: > Looking around for a way to get the connection on deserialisation, I ran > into #14914 <https://code.djangoproject.com/ticket/14914> which was closed > wontfix 3 years ago with a request for a use case for the change. > > Here is my use case: > > I'm writing an encrypted char field, with encryption happening at the > database end (MS-SQL). Decryption looks a bit like this: > > ---- > OPEN SYMMETRIC KEY keyname > DECRYPTION BY CERTIFICATE somecertificate > > SELECT CAST(DECRYPTBYKEY(fieldname) AS VARCHAR(2048)) > FROM atable > > CLOSE SYMMETRIC KEY keyname > ---- > > and analogously for the encryption. > > The way I thought of doing that was by modifying get_db_prep_value for > encryption and to_python for decryption, but I ran into the lack of > connection at the to_python stage, and nothing like to_db_python. > Does this constitute a legitimate use case for to_db_python or is there a > better way to go about this? > Note: I'd prefer if any discussion would stay away from the validity of > using DB-based symmetric encryption on specific fields. > > In the more general sense, I'd expect the method to be useful for any > stored-procedure-heavy location where the extracted field has to be > post-processed by some function that runs on the database to be made sense > of. > > Thanks > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
