Re: Schema tests: delete_tables

On Tue, May 20, 2014 at 7:19 AM, Michael Manfre wrote: > > > I didn't notice those problems back in January with my pull request > (closed as won't merge) that made this exact change. [1] I haven't devoted > much time toward testing schema migrations since, so perhaps the >

Re: Schema tests: delete_tables

On Tue, May 20, 2014 at 8:11 AM, Andrew Godwin wrote: > Hi all, > > It's done as a raw DROP TABLE because it has to run in weird situations > with transactions and models where the core delete_model doesn't work (if > you swap it out, you'll see other failures). We can

Re: [GSOC] Weekly update

Best of luck! On Tuesday, 20 May 2014 03:56:06 UTC+10, Daniel Pyrathon wrote: > > Hi All, > > Today I will be starting my weekly updates on my SoC project: refactoring > Meta to a stable API. For anyone who missed out, you will be able to view > it here: >

Re: django-firebird backend: migrations and NULL fields

Yes, I'm aware add_field is also in need of expansion points - the same issue was raised with the MSSQL backend too. I'm more than happy to add these in now or after 1.7 in a point release; the actual implementation of those methods is private so we can change it around a little (or at least, we

Re: Schema tests: delete_tables

Hi all, It's done as a raw DROP TABLE because it has to run in weird situations with transactions and models where the core delete_model doesn't work (if you swap it out, you'll see other failures). We can definitely work towards improving this, perhaps by moving this onto a method on the

Re: Schema tests: delete_tables

Hi Maximiliano, Michael Thanks for the clarification. I'm not 100% up to speed with the new migrations code, but I agree that this looks odd; it's certainly worth opening a ticket so that the issue isn't forgotten. It's even arguable that this might be a 1.7 blocker; even though it isn't a

Re: Schema tests: delete_tables

Hi Michel, Thank to explain it better than me. Regards. El martes, 20 de mayo de 2014 00:42:35 UTC-3, Michael Manfre escribió: > > Hi Russell, > > I understand what Maximiliano is asking. It's a flaw with > SchemaTests.delete_tables [1] and it is essentially doing a raw drop table, > instead

Re: inspectdb and non "public" schema in postgresql

If I understand correctly, your legacy database is not in "public" schema. Django offers no support for Postgres schemas, it's left to the developer/ops people to have correct search_path set. There are two possible fixes for you: - set Postgres user default search path to contain your schema -

Automatically get default value for "current_app", for easier namespace support.

Right now it seems that for a generic app to support the possibility of being installed in a URLconf with a namespace, the app author will need to take care to explicitly define a `current_app` for every call to `reverse()`, `TemplateResponse`, `RequestContext`, `Context` and `{% url %}`.