i actually didnt try the db_column attribute because I read about quoting it before I started writing the code. But that wont solve the schema problem. It will still try to create the index and fk constraints with the dots and quotes around the table name.
i believe it is required to quote the schema and table name in the db_table property as '"dim"."Application"', if you left it as 'dim.Application' it would create the table as 'dim.application' and if it quoted it it would still be wrong as "dim.Application"...that will fail also On the schema question, yes adding a db_schema property and all the supporting code sounds like it would fit well...you can create fk's to tables in diff schemas. Craig On Thu, Apr 12, 2012 at 7:25 PM, Jeremy Dunck <jdu...@gmail.com> wrote: > On Thu, Apr 12, 2012 at 3:06 PM, Craig Lucas <craigmlu...@gmail.com> > wrote: > > i have developed a database for a client that uses camel casing in the > > database. we are now trying to get a models.py file to mimic the > > database structure and i have run into a few bugs with regards to > > using quoted table names. > > > > The first issue is when you specify a foreign key field it takes the > > table name + the field name to generate a unique constraint name. This > > logic does not take into consideration that the field name has quotes > > around it so it fails when executing the sql to create the foreign key > > constraint. This wouldnt be so much of a problem if you could specify > > the name of the foreign key (which I use through the related_name > > parameter) and the engine would actually use it as the constraint > > name. > > Did the db_column attribute not work for this? You shouldn't need to > do literal quotes in the value you pass to db_column - django > generally quotes field names in all cases. > https://docs.djangoproject.com/en/1.4/ref/models/fields/#db-column > > > The next problem is somewhat similar. The django toolkit tries to > > automatically create indexes on foreign key fields but doesnt take > > into consideration that the table has quotes around it OR that the > > table is in a schema. > > Note that I override the db_table to force it to be in a schema. > > > > In the django code in creation.py: > > > > def get_index_sql(index_name, opclass=''): > > return (style.SQL_KEYWORD('CREATE INDEX') + ' ' + > > > > > style.SQL_TABLE(qn(truncate_name(index_name,self.connection.ops.max_name_length()))).replace('"','').replace('.', > > '_') + ' ' + > > style.SQL_KEYWORD('ON') + ' ' + > > style.SQL_TABLE(qn(db_table)) + ' ' + > > "(%s%s)" % (style.SQL_FIELD(qn(f.column)), > > opclass) + > > "%s;" % tablespace_sql) > > > > I have added the ".replace('"','').replace('.', '_')" part to format > > the name properly to account for customized table names. > > You're right that there isn't support for schema, though there is for > db_table, db_column and db_tablespace. I think db_schema fits fine, > as long as the semantics make sense - I know schema is a common > concept, but do different backends have a similar notion? Can foreign > keys to schemas be done, for example? > > ... > > ApplicationKey = models.AutoField(primary_key=True, db_column = > > '"ApplicationKey"') > > For what it's worth, I would have expected this to work: > ApplicationKey = models.AutoField(primary_key=True, db_column = > 'ApplicationKey') > > And to be more pythonic: > application_key = models.AutoField(primary_key=True, > db_column='ApplicationKey') > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
