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
> transactions issues we
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 definitely work towards
> i
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:
> https://docs.google.com/document/d/1yp
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 c
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 backend.
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 proble
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 o
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
- h
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
%}`.
Djan
