Re: Schema tests: delete_tables

2014-05-20 Thread Andrew Godwin 
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 were introduced sometime later.
>

Then I may be mistaken; I put that in place last year, but I've changed the
way test and dropped tables work several times since then, so it might be
that we can do it directly now.


>
> Your statement effectively turns Django in to Windows by encouraging a
> subset of the users to wait until a service pack or entirely skip a
> version. If schema migrations are not properly supported by a backend, it
> could easily lead to data issues. Missing or wrong constraints are a PITA
> to track down. If a 3rd party backend author cannot validate that it is
> working as expected, they might choose to not support 1.7.0 and hold their
> end-users back until the necessary fixes make their way in to Django.
>
> I personally don't care whether or not this is deemed a release blocker. I
> tried to be proactive with 1.7 by devoting a lot of time and effort trying
> to get changes in, but in the end I gave up frustrated. My 1.7 plan is to
> wait until it's released and then review schema migrations' growing list of
> "we'll fix it later" issues and monkey patch as necessary.
>
>
You're not the only frustrated one here. The list of release blockers seems
to grow more than it shrinks, and it seems like we'll never get 1.7
shipped. I value third-party backends highly - I've used the MSSQL one
before and saved a ton of time - but at the same time we're already a week
behind schedule and at the current rate might be several months behind.

There are _going_ to be bugs found in the 1.7 release; only a fraction of
our users test with betas, though thankfully it has been more this time.
The thinking behind pushing things like this into a 1.7.1 release was that
we can at least get a release out for the bundled backends and get people
using those while I work with third-party backends to get integration
better and code duplication down.

I'm sorry I seem a bit snappy with this stuff, but I've spent the past few
months slowly squashing migration bugs while dealing with moving continent
and battling RSI. I _have_ to prioritise things, and I'm going to annoy
people no matter which way I turn. We'll get the integration stuff sorted,
I just have to fix the bugs that affect everything first. Perhaps this
should be in 1.7, perhaps it shouldn't; without input from you and others
it's just left to me to decide, and I always tend towards a "ship early,
ship often" style, sometimes too far (as South users sometimes see).

Andrew

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/CAFwN1urTyguqtsgZ0Y2gzTNWRUQeFwOCXPorEJMAXOs6PJCXPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Schema tests: delete_tables

2014-05-20 Thread Michael Manfre 
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
> improving this, perhaps by moving this onto a method on the backend.
>

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 were introduced sometime later.

[1]
https://github.com/manfre/django/commit/27d69e0134d0ab5b668c954eec0234c1e4e7d3ee#diff-12(also
https://github.com/manfre/django/commit/5167bc1aaf225588f128c89ffe2c580df1bdaf35to
explicitly close those cursors)


> However, I disagree that it is a release blocker. We're inevitably going
> to have a 1.7 point release anyway, 1.7.0 is not some time where everything
> like this gets clad in stone, and these tests are only for the backends
> themselves, not for end-users to run.
>

Your statement effectively turns Django in to Windows by encouraging a
subset of the users to wait until a service pack or entirely skip a
version. If schema migrations are not properly supported by a backend, it
could easily lead to data issues. Missing or wrong constraints are a PITA
to track down. If a 3rd party backend author cannot validate that it is
working as expected, they might choose to not support 1.7.0 and hold their
end-users back until the necessary fixes make their way in to Django.

I personally don't care whether or not this is deemed a release blocker. I
tried to be proactive with 1.7 by devoting a lot of time and effort trying
to get changes in, but in the end I gave up frustrated. My 1.7 plan is to
wait until it's released and then review schema migrations' growing list of
"we'll fix it later" issues and monkey patch as necessary.

Regards,
Michael Manfre

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/CAGdCwBv8EM7%3D2QiBmmr051_Y_5qF0xhX2xxTrthL0hcVTCrfcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Weekly update

2014-05-20 Thread Josh Smeaton 
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/1yp2_skqkxyrc0egdRv6ofnRGCI9nmvxDFBkCXgy0Jwo/edit
>
> This week is the first official week of SoC. Me and my mentor (Russell) 
> are initially approaching the work in the following way:
>
>- *Document the existing Meta API*
>For each endpoint, document the following:
>  - Input parameters and return type
>  - Caching pattern used
>  - Where it's called from (internally and externally to Meta)
>  - Why is it being called
>  - When is it being called
>
>- *Propose an initial refactor plan*
>Once the documentation has been done, I should have a better idea of 
>the current implementation. This will allow me to mock a proposed 
>implementation that will be reviewed at my next update call, on Monday.
>
> My next update will be posted on Friday, just to make sure the community 
> is informed of my progress. For any major updates that require community 
> approval, I will be creating separate threads.
> My name on the internet is pirosb3, so if you want to have a chat about my 
> progress feel free to contact me! The branch I am currently working on is 
> https://github.com/PirosB3/django/tree/meta_documentation
>
> Regards,
> Daniel Pyrathon
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/3b7fbdbd-0015-4d2a-919d-01c5713c0c27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-firebird backend: migrations and NULL fields

2014-05-20 Thread Andrew Godwin 
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 can add to the available overrides; I
wouldn't go removing those things on backend implementers like yourself).

I've also added the implied_column_null database feature in this commit:
https://github.com/django/django/commit/1b07781292c2cef9367b521dc0f2b40f4d363083

Just set it to True and you should get the behaviour you need.

Andrew


On Fri, May 16, 2014 at 10:00 PM, Maximiliano Robaina  wrote:

>
>
> El viernes, 16 de mayo de 2014 09:49:15 UTC-3, Andrew Godwin escribió:
>
>> Let's go with a feature for this then.
>>
>> Maxi, did you want to submit a patch, or do you want me to add it at some
>> point next week!
>>
>> Andrew
>>
>
> I'll appreciate if you can add it.
> BTW, are there other areas that need some work, for instance, add_field
> method [1], if I try to delete a default value on a column that does not
> have a previous default value definition I get an error on firebird, for
> which reason, I need to check if that field has got defined a default value
> before.
> Then I need to rewrite add_field method too.
> I think, for not to delay django 1.7 release, I'll do some workaround and
> I'll try to send you a pull request or a patch with some proposal later.
>
> [1]
> https://github.com/django/django/blob/master/django/db/backends/schema.py#L401
>
>
> Best regards.
>
>
>>
>>
>> On Wed, May 14, 2014 at 6:27 PM, Aymeric Augustin > polytechnique.org> wrote:
>>
>>> For what it’s worth, I recently added a feature to add “FROM DUAL” where
>>> Oracle needs it.
>>>
>>> This looks roughly similar. Maybe we could use the same approach. (I
>>> didn’t look closely.)
>>>
>>> --
>>> Aymeric.
>>>
>>>
>>>
>>> On 14 mai 2014, at 17:06, Andrew Godwin  wrote:
>>>
>>> Hmm, I'm not sure about adding more features, but it might be cleaner...
>>>
>>> Andrew
>>>
>>>
>>> On Wed, May 14, 2014 at 8:00 AM, Jeremy Dunck  wrote:
>>>
 How about adding a flag to Operations? implied_null, perhaps.
 On May 14, 2014 7:52 AM, "Andrew Godwin"  wrote:

> Hi,
>
> That's currently the only approach I'm afraid - there's an open issue
> (raised by Shai Berger I believe) that column_sql should be broken down
> into more component pieces so it can be more easily changed, but that's a
> difficult task to do and not something I want to go and change completely
> as we're trying to release 1.7.
>
> What we could do is change those NULL and NOT NULL strings to be
> defined on the schema editor class itself, and then you could set
> sql_null_suffix = "" or similar - do you think that would be a reasonable
> approach?
>
> Andrew
>
>
> On Wed, May 14, 2014 at 7:05 AM, maxi  wrote:
>
>> Hi,
>>
>> I'm trying to implement the new schema migration of django 1.7 for
>> django-firebird backend.
>> In column_sql method, when the field can be null, in firebird, is not
>> necessary add the NULL keyword. So to change this behavior I need 
>> override
>> the entire column_sql method just to change one line:
>>
>>
>> if null:
>> sql += " NULL"<-- Here
>> else:
>> sql += " NOT NULL"
>>
>> I just need:
>> if not null:
>> sql += " NOT NULL"
>>
>>
>> Is the correct approach rewrite the column_sql method? Are there
>> other approach?
>>
>> Regards.
>>
>> --
>> 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 django-develop...@googlegroups.com.
>> To post to this group, send email to django-d...@googlegroups.com.
>>
>> 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/e9f2-a5bf-4e13-b7c1-
>> 0a08abd18a4a%40googlegroups.com
>> .
>> 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 django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
>
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.g

Re: Schema tests: delete_tables

2014-05-20 Thread Andrew Godwin 
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.

However, I disagree that it is a release blocker. We're inevitably going to
have a 1.7 point release anyway, 1.7.0 is not some time where everything
like this gets clad in stone, and these tests are only for the backends
themselves, not for end-users to run.

Andrew


On Tue, May 20, 2014 at 4:55 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> 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 problem with "official" database backends, if we're
> serious about supporting third party backends, we shouldn't publish a test
> suite that we know they can't run.
>
> Yours,
> Russ Magee %-)
>
> On Tue, May 20, 2014 at 7:30 PM, Maximiliano Robaina <
> maxiroba...@gmail.com> wrote:
>
>> 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 of using the 3rd party backend friendly SchemaEditor.delete_model
>>> [2]. There was the last time I checked (and still exists) a lot of raw SQL
>>> in the schema tests that caused tests to fail for django-mssql. It appears
>>> other non-core backends are also facing these issues.
>>>
>>> Regards,
>>> Michael Manfre
>>>
>>> [1] https://github.com/django/django/blob/stable/1.7.x/
>>> tests/schema/tests.py#L38
>>> [2] https://github.com/django/django/blob/stable/1.7.x/
>>> django/db/backends/schema.py#L274
>>>
>>>
>>> On Mon, May 19, 2014 at 10:45 PM, Russell Keith-Magee <
>>> rus...@keith-magee.com> wrote:
>>>

 On Tue, May 20, 2014 at 7:07 AM, Maximiliano Robaina <
 maxir...@gmail.com> wrote:

> Hi,
>
> Running tests, (I'm using firebird) in schema app, I see that the
> tearDown method deletes all tables created by each test. The problem here
> is for tables with AutoInc field where sequences are created 
> independently,
>  when the table is dropped we need delete the sequence object too.
> The, to me, customized delete_model method from schema editor do that,
> when the model is deleted, then the sequence is deleted if any.
>
> So, the delete_tables method used in tearDown, needs to delete the
> correlated sequences either calling to drop_sequence_sql from
> DatabaseOperations or implementing something in Schema editor.
>
> Hi Maximiliano,

 It's not clear (to me, at least) what you're asking for here.

 In the general case, resetting sequences *shoudn't* be needed as part
 of a test suite. Tests that are dependent on a specific PK value being
 allocated are wrong by design, because you simply can't guarantee
 allocation order in a database.

 If you've got a specialist sequence being used as a part of a
 particular model, then you might need to have some custom code to reset
 particular sequences… but then, you're dealing with a custom scenario, in
 which case I don't think it's unreasonable to require some custom reset
 code as part of your test.

 If this is a Firebird specific issue, then it isn't clear to me why the
 statements you need can't be integrated into the flushing infrastructure
 that is already in place. In all the built-in backends, the tearDown method
 on tests doesn't *delete* tables, it flushes them; sequences are reset as
 part of that process. If Firebird requires something extra, you're going to
 need to give us a specific proposal for a database API modification that
 would meet your needs.

 Yours,
 Russ Magee %-)


 --
 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 django-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.

 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/CAJxq84-Nu9gVDdwJWGu-
 LuEoSpUCQyY2KWN1Kt5o9YquejURyw%40mail.gmail.com
 .

 F

Re: Schema tests: delete_tables

2014-05-20 Thread Russell Keith-Magee 
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 problem with "official" database backends, if we're
serious about supporting third party backends, we shouldn't publish a test
suite that we know they can't run.

Yours,
Russ Magee %-)

On Tue, May 20, 2014 at 7:30 PM, Maximiliano Robaina
wrote:

> 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 of using the 3rd party backend friendly SchemaEditor.delete_model
>> [2]. There was the last time I checked (and still exists) a lot of raw SQL
>> in the schema tests that caused tests to fail for django-mssql. It appears
>> other non-core backends are also facing these issues.
>>
>> Regards,
>> Michael Manfre
>>
>> [1] https://github.com/django/django/blob/stable/1.7.x/
>> tests/schema/tests.py#L38
>> [2] https://github.com/django/django/blob/stable/1.7.x/
>> django/db/backends/schema.py#L274
>>
>>
>> On Mon, May 19, 2014 at 10:45 PM, Russell Keith-Magee <
>> rus...@keith-magee.com> wrote:
>>
>>>
>>> On Tue, May 20, 2014 at 7:07 AM, Maximiliano Robaina >> > wrote:
>>>
 Hi,

 Running tests, (I'm using firebird) in schema app, I see that the
 tearDown method deletes all tables created by each test. The problem here
 is for tables with AutoInc field where sequences are created independently,
  when the table is dropped we need delete the sequence object too.
 The, to me, customized delete_model method from schema editor do that,
 when the model is deleted, then the sequence is deleted if any.

 So, the delete_tables method used in tearDown, needs to delete the
 correlated sequences either calling to drop_sequence_sql from
 DatabaseOperations or implementing something in Schema editor.

 Hi Maximiliano,
>>>
>>> It's not clear (to me, at least) what you're asking for here.
>>>
>>> In the general case, resetting sequences *shoudn't* be needed as part of
>>> a test suite. Tests that are dependent on a specific PK value being
>>> allocated are wrong by design, because you simply can't guarantee
>>> allocation order in a database.
>>>
>>> If you've got a specialist sequence being used as a part of a particular
>>> model, then you might need to have some custom code to reset particular
>>> sequences… but then, you're dealing with a custom scenario, in which case I
>>> don't think it's unreasonable to require some custom reset code as part of
>>> your test.
>>>
>>> If this is a Firebird specific issue, then it isn't clear to me why the
>>> statements you need can't be integrated into the flushing infrastructure
>>> that is already in place. In all the built-in backends, the tearDown method
>>> on tests doesn't *delete* tables, it flushes them; sequences are reset as
>>> part of that process. If Firebird requires something extra, you're going to
>>> need to give us a specific proposal for a database API modification that
>>> would meet your needs.
>>>
>>> Yours,
>>> Russ Magee %-)
>>>
>>>
>>> --
>>> 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 django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>>
>>> 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/CAJxq84-Nu9gVDdwJWGu-
>>> LuEoSpUCQyY2KWN1Kt5o9YquejURyw%40mail.gmail.com
>>> .
>>>
>>> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> 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/1e76f781-48b3-4ae2-b2de-3e3f8d0e21f1%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

Re: Schema tests: delete_tables

2014-05-20 Thread Maximiliano Robaina 
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 of using the 3rd party backend friendly SchemaEditor.delete_model 
> [2]. There was the last time I checked (and still exists) a lot of raw SQL 
> in the schema tests that caused tests to fail for django-mssql. It appears 
> other non-core backends are also facing these issues.
>
> Regards,
> Michael Manfre
>
> [1] 
> https://github.com/django/django/blob/stable/1.7.x/tests/schema/tests.py#L38
> [2] 
> https://github.com/django/django/blob/stable/1.7.x/django/db/backends/schema.py#L274
>
>
> On Mon, May 19, 2014 at 10:45 PM, Russell Keith-Magee <
> rus...@keith-magee.com > wrote:
>
>>
>> On Tue, May 20, 2014 at 7:07 AM, Maximiliano Robaina 
>> 
>> > wrote:
>>
>>> Hi,
>>>
>>> Running tests, (I'm using firebird) in schema app, I see that the 
>>> tearDown method deletes all tables created by each test. The problem here 
>>> is for tables with AutoInc field where sequences are created independently, 
>>>  when the table is dropped we need delete the sequence object too.
>>> The, to me, customized delete_model method from schema editor do that, 
>>> when the model is deleted, then the sequence is deleted if any.
>>>
>>> So, the delete_tables method used in tearDown, needs to delete the 
>>> correlated sequences either calling to drop_sequence_sql from 
>>> DatabaseOperations or implementing something in Schema editor.
>>>
>>> Hi Maximiliano,
>>
>> It's not clear (to me, at least) what you're asking for here. 
>>
>> In the general case, resetting sequences *shoudn't* be needed as part of 
>> a test suite. Tests that are dependent on a specific PK value being 
>> allocated are wrong by design, because you simply can't guarantee 
>> allocation order in a database.
>>
>> If you've got a specialist sequence being used as a part of a particular 
>> model, then you might need to have some custom code to reset particular 
>> sequences… but then, you're dealing with a custom scenario, in which case I 
>> don't think it's unreasonable to require some custom reset code as part of 
>> your test.
>>
>> If this is a Firebird specific issue, then it isn't clear to me why the 
>> statements you need can't be integrated into the flushing infrastructure 
>> that is already in place. In all the built-in backends, the tearDown method 
>> on tests doesn't *delete* tables, it flushes them; sequences are reset as 
>> part of that process. If Firebird requires something extra, you're going to 
>> need to give us a specific proposal for a database API modification that 
>> would meet your needs. 
>>
>> Yours,
>> Russ Magee %-)
>>  
>>
>> -- 
>> 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 django-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> 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/CAJxq84-Nu9gVDdwJWGu-LuEoSpUCQyY2KWN1Kt5o9YquejURyw%40mail.gmail.com
>> .
>>
>> 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/1e76f781-48b3-4ae2-b2de-3e3f8d0e21f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: inspectdb and non "public" schema in postgresql

2014-05-20 Thread Tomek Paczkowski 
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
- hook into connection_created signal and set search pach manually[1]

[1]: https://docs.djangoproject.com/en/dev/ref/signals/#connection-created

On Monday, May 19, 2014 11:38:20 PM UTC+2, Fabio Caritas Barrionuevo da Luz 
wrote:
>
> Hello Django core developers.
> Sorry if this is not the correct place to handle this.
>
> I have a legacy database in PostgreSQL, which is still in production.
> I want to migrate it to Django. 
> I tried to do the reverse engineering of the database to generate models 
> classes
>
> I set my settings like this:
>
> DATABASES = {
> # this read/write into "public" postgresql schema
> 'default': {
> 'ENGINE': 'django.db.backends.postgresql_psycopg2',
> 'NAME': 'neweposse',
> 'USER': 'neweposse_user',
> 'PASSWORD': 'neweposse_user',
> 'HOST': '127.0.0.1',
> 'PORT': '5432',  
> },
> # legacy database
> 'eposse': {
> 'ENGINE': 'django.db.backends.postgresql_psycopg2',
> 'NAME': 'eposse',
> 'USER': 'eposse_user',
> 'PASSWORD': 'eposse_user',
> 'HOST': '127.0.0.1',
> 'PORT': '5432',
> }
> }
>
>
> in terminal:
>
> (django1.7a5)sutransdev@sutransdev:~/webdocpy$ python manage.py inspectdb
> ...
> from __future__ import unicode_literals
>
> from django.db import models
>
> (django1.7a5)sutransdev@sutransdev:~/webdocpy$ python manage.py inspectdb 
> --database=eposse
> ...
> from __future__ import unicode_literals
>
> from django.db import models
>
>
>
> inspectdb not identify the tables in the database and does not generate 
> the model classes
>
>
> The question is?
>
> 1) Am I doing something wrong. Currently there any way he could get Django 
> to recognize a schema different from the "public" database schema? 
>
> 2) This is really a bug, and I need to create a ticket for this? 
>
> 3) or Django does not currently support different database schema, but 
> this feature will be added when Marc Tamlyn add enhanced features to 
> postgresql, as described here:
>
> https://www.kickstarter.com/projects/mjtamlyn/improved-postgresql-support-in-django?
>
>
>
> Thanks for the hard work to maintain this great framework
>
>
>
> -- 
> Fábio C. Barrionuevo da Luz
> Acadêmico de Sistemas de Informação na Faculdade Católica do Tocantins - 
> FACTO
> Palmas - Tocantins - Brasil - América do Sul
>  

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/31a94b4b-d1a7-43bf-9468-bd8f65835f01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2014-05-20 Thread Tai Lee 
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 
%}`.

Django already adds a `ResolverMatch` object to every request. Shouldn't 
Django just use this to get a default value for "current_app", whenever 
users don't explicitly define one?

This should make it almost a non-issue to define the current app for every 
case except explicit calls to `reverse()`, `Context` and templates that are 
rendered without a `RequestContext` object (as none of these have access to 
the request).

We could even get a sensible default in those cases as well by storing the 
current app in thread local storage, and using that as a default in 
`reverse()`.

I've made a ticket for this, but it was closed as wontfix because thread 
local storage is global state and Django is at war with global state.

https://code.djangoproject.com/ticket/22203

As suggested, I'm bringing this to django-developers to ask for any 
alternative suggestions that don't involve global state, and also to try 
and make my case for the ticket as originally described.

Django already uses `threading.local()` in a number of places such as 
`urlresolvers._prefixes`, `urlresolvers._urlconfs`, `CacheHandler._caches`, 
`ConnectionHandler._connections`, `trans_real._active`, `timezone._active`.

The most notably similar use case is probably for timezone support, which 
allows users to call `activate()` to tell Django what timezone they are in, 
and then other parts of the code call `get_current_timezone()` to get the 
value stored in thread local storage.

I think it would be along the same lines to have the ability to set a 
current app and have other parts of the code get the current app, without 
having to pass an object around as an argument every step of the way, which 
is practically impossible.

For example, models with a `get_absolute_url` method (or perhaps multiple 
`get_foo_url` methods) that are rendered in templates. These functions 
can't take arguments when rendered as context variables in a template, and 
have no way to obtain the current namespace from the `request` object.

This would make it super easy for users (via middleware) or Django itself 
to inspect the `request.resolver_match` object and set the current app 
early in the request/response cycle, and then `reverse()` and `{% url %}` 
would just work without generic app authors having to explicitly build in 
support for multiple instances of their app being deployed within a single 
project.

Does anyone else think this would be a good idea, or does anyone have an 
alternative suggestion?

Cheers.
Tai.

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/a7a8b2fb-91db-4b0a-ac1b-d76c5df38aa7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.