At the moment you'll need to make sure both Creation and SchemaEditor do
the right thing for stuff like that. We bumped "deprecate DatabaseCreation"
back to 2.0 for a final removal as it was so complex and so much stuff
relies on it (including SchemaEditor in places where I didn't want to
duplicate code; we'll move that code over eventually)

Andrew


On Mon, Jul 28, 2014 at 2:33 AM, Tim Graham <[email protected]> wrote:

> FWIW, I may have closed that PR prematurely. I didn't realize SchemaEditor
> still relied on DatabaseCreation and I'm not sure what the final
> combination of the two will ultimately look like.
>
>
> On Sunday, July 27, 2014 7:38:08 AM UTC-4, Christopher D'Cunha wrote:
>>
>> Hi All,
>>
>> I'm working on https://code.djangoproject.com/ticket/56 for the
>> EuroPython sprint. There was a PR for it (https://github.com/django/
>> django/pull/1156) but it was rejected by Tim Graham because the code
>> should apparently be in the SchemaEditor instead of the DatabaseCreation
>> class.
>>
>> As I trace through though I see that the SchemaEditor uses the
>> DatabaseCreation for some stuff. For example, in order to get the column
>> type for a field:
>>
>>
>> # /django/db/backends/schema.py
>>
>> class BaseDatabaseSchemaEditor(object):
>>     ...
>>
>>     def create_model(self, model):
>>          ...
>>
>>         for field in model._meta.local_fields:
>>             ...
>>
>>             # Check constraints can go on the column SQL here
>>             db_params = field.db_parameters(connection=self.connection)
>>
>>
>> # /django/db/models/fields/__init__.py
>>
>> class Field(RegisterLookupMixin):
>>     """Base class for all field types"""
>>
>>     ...
>>
>>     def db_parameters(self, connection):
>>         ...
>>         type_string = self.db_type(connection)
>>         ...
>>
>>     def db_type(self, connection):
>>         data = DictWrapper(self.__dict__, connection.ops.quote_name,
>> "qn_")
>>         try:
>>             return connection.creation.data_
>> types[self.get_internal_type()] % data
>>         except KeyError:
>>             return None
>>
>> Is it possible/worth it for me to work on #56 before all the "migrate"
>> stuff is done?
>>
>> +AndrewGodwin, I'm told that you're the best person to ask :D.
>>
>> Thanks,
>> Chris
>>
>  --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/abd10460-694f-4c89-88c2-a9b06b7a6eca%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/abd10460-694f-4c89-88c2-a9b06b7a6eca%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1uqdSO64Uc4FHJtwEWeU5x%3Ddw59ij%2By%2Bsq%2B4sux_yZ6Ogg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to