Re: Schema tests: delete_tables

[Michael Manfre]

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 <
russ...@keith-magee.com> wrote:

>
> On Tue, May 20, 2014 at 7:07 AM, Maximiliano Robaina <
> maxiroba...@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-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/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/CAGdCwBvf2o0neGVDogsyBuc%2BZPmE%2Bkfg_N5jCRtnedfNmWRdQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Schema tests: delete_tables

[Russell Keith-Magee]

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-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/CAJxq84-Nu9gVDdwJWGu-LuEoSpUCQyY2KWN1Kt5o9YquejURyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: inspectdb and non "public" schema in postgresql

[Russell Keith-Magee]

On Tue, May 20, 2014 at 5:38 AM, Fabio C. Barrionuevo da Luz <
bna...@gmail.com> wrote:

> Hello Django core developers.
> Sorry if this is not the correct place to handle this.
>

Not really - this mailing list is for discussing the development of Django
itself, not for solving usage questions.


> 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?
>

Well, there's *something* going wrong. inspectdb definitely works if you
point it at a PostgreSQL database. I can only assume that either:

 a) The "neweposse" and "eposse" databases are actually empty, and don't
actually contain schema, or

 b) An error is being raised when connecting to the database, which is
being silenced incorrectly

If (b) is happening, that would be a bug; you can check if this is the case
by running "manage.py dbshell"; if you can't connect a shell to the
database, inspectdb won't work either. If dbshell *does* work, then you can
run /dt to confirm that tables actually exist in the database.


> 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?
>
>
AFAIK, nothing Marc is doing will change inspectdb functionality.

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-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/CAJxq84-0-0-WOqjrOHz3mh1Z%3DU9yu1c_wrVqPJBD5mXrDWt%3DHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #22383 Add the HTML5 required tag to the input fields which are required for database entry

[Tim Graham]

Here is a more concrete proposal based on Loic's comment in the ticket:

A normal deprecation cycle based on the value of a new `
use_required_attribute` boolean attribute on forms.

To deprecate you could do:

class form.Form(object):
#...
use_required_attribute = None

class BoundField(object):
#...
def as_widget():
if self.form.use_required_attribute is None:
warnings.warn("The required attribute will be turned on by default 
in Django X.X unless you opt-out.")
elif form.use_required_attribute:
attrs['required'] = True

Now what happens next depends on the actual goal, do we want to use 
use_required_attribute as a permanent way to control this feature, or as a 
mere deprecation tool.

Personally I'm (Loic) not thrilled by this feature, although I know lot of 
people will want it, so I'd like to keep the switch.

Another point of interest, right now there is no way to tell a form that it 
should render as HTML4 or HTML5. When we discussed 
#20684 we 
acknowledged that if someone really cared about HTML4 validation, they 
could use required="required" instead of required=True, but if this becomes 
the default and we kill use_required_attribute, we'd be outputting HTML5.

On Friday, April 11, 2014 3:51:41 AM UTC-4, anubhav joshi wrote:
>
>
>
> On Friday, April 11, 2014 4:57:33 AM UTC+5:30, Gregor Müllegger wrote:
>>
>> I think adding the `required` attribute but ignoring the other possible 
>> html form validations (like `min` and `max` [1] for  that are used 
>> by the forms.IntegerField) seems a bit half-hearted.
>>
>> My opinion is that having the required attribute is pretty cool, but 
>> should come with all other possible validations baked in then.
>> django-floppyforms already includes those validations already in the HTML 
>> output of forms and it turns out to be quite useful in many situations. 
>> Even if you turn of the browser validation by adding the novalidate 
>> attribute to the  tag, it's good to have this meta data in the HTML 
>> representation, e.g. for styling.
>>
>> Gregor
>>
>
> Thanks Gregor, but I think here we first need to make it clear do we 
> really want it. 
>

-- 
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/738084b9-e1b6-410c-8b35-f3ca0598aed4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Schema tests: delete_tables

[Maximiliano Robaina]

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.


---
Maxi

-- 
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/1b7ca4ce-6cc6-4191-9b6a-dc61ec3d717e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

inspectdb and non "public" schema in postgresql

[Fabio C. Barrionuevo da Luz]

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/CAPVjvMbBtYVosVxxU39PvxEmAuz5ociyPbHSecH%2Bcn777RuQKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database-dependant tests and third-party backends

[Rahul]

DECIMAL datatype of DB2 also doesn't supports max_digits 38 and 
decimal_places = 30. In DB2 precision range defined between 1 to 31 and In 
firebird range is 1 to 18(ref 
http://www.promotic.eu/en/pmdoc/Subsystems/Db/FireBird/DataTypes.htm)

It would be good if max_digits and decimal_places can be changed in the 
range which is valid for Django's 3rd party backends also. 

-- 
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/288e325a-bc1b-4818-8684-0069a06f7751%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[GSOC] Weekly update

[Daniel Pyrathon]

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/c0d9a1f7-4fae-4c47-aae1-59b472c46939%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database-dependant tests and third-party backends

[Maximiliano Robaina]

El miércoles, 7 de mayo de 2014 22:03:11 UTC-3, Russell Keith-Magee 
escribió:
>
>
> On Thu, May 8, 2014 at 12:40 AM, Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>
>> Hello,
>>
>> I'm trying to make the lives of maintainers of third-party database 
>> backends a bit easier.
>>
>  
> +1. Very much in support of this as a general principle.
>  
>
>> I'm specifically interested in MSSQL backends. Unlike Oracle, it isn't 
>> supported by Django out of the box, but it's a very common database. The 
>> most robust implementation, django-mssql, is very close to passing Django's 
>> entire test suite in addition to its own test suite.
>>
>> Currrently Django uses two solutions for database-dependant tests, both 
>> of which would require small adjustments to support third-party backends 
>> adequately.
>>
>> *1) Checking database features*
>>
>> This is the correct solution for database-dependant tests in general.
>>
>> *What do you think of adding feature flags that have the same value for 
>> all core backends but may be set to a different value by third-party 
>> backends?*
>>
>> With a comment explaining which backends use the flag and what it does, I 
>> find it acceptable. Then we would skip some tests based on the flag.
>>
>
> From a purely technical perspective, this is the right approach AFAICT.
>  
> The catch is at a project management level. By doing this, we're 
> introducing code branches, but our own testing won't be able able to 
> execute the "other" branch, so our release testing coverage will be 
> deficient. From a testing perspective, this makes me a little nervous, as 
> we're essentially relying on third party backend providers to (a) tell us 
> which flags are needed (b) when/where then need to be applied, and (c ) to 
> respond in a timely fashion during the release process to make sure the 
> flags are all up to date.
>
> *2) Checking connection.vendor*
>>
>> This is often inferior to feature flags.
>>
>> Positive checking ("run this test only for SQLite") is reasonable. At 
>> worst, the test is skipped on third-party databases where it could pass.
>>
>> Negative checking ("run this test on all databases except Oracle") is 
>> more problematic. If a third-party backend also fails the test, there's no 
>> easy way to ignore it.
>>
>> Conditional code ("do X for vendors A, B and C, do Y for other vendors") 
>> is also problematic. All third-party backends will do Y, which may or may 
>> not be the right behaviour.
>>
>> *Would you object to adding "microsoft" to explicit checks for 
>> connection.vendor where appropriate?*
>>
>
> I'm less convinced this is a good idea. Vendor flags were introduced as 
> part of the introduction of unittest2 to Django's core. In retrospect, the 
> role being played by 'vendor' should probably implemented as a specific 
> feature. There might be a light documentation benefit from having 
> backend.vendor, but I'm not convinced we should be leaning on it heavily 
> for testing purposes, and I'm definitely not convinced adding references to 
> vendors that aren't part of Django's official codebase is a good idea. 
>
> The good news here is that your PR #2640 seems to bear this out.
>
> While we're on the subject of providing better support to third party 
> backends - I've floated this idea in the past, but now seems an opportune 
> time to discuss again: I'd like to be able to expand our testing 
> infrastructure to include automated testing of projects that are 
> significant to the community. Database backends are particularly relevant 
> here, but things like DDT, Django-registration, and django-rest-framework 
> probably also fall under this umbrella. The idea here would be:
>
>  1) to give us (as the core team) better visibility when we make a change 
> that is going to have an big impact on the community
>  2) to ensure that the community knows what libraries in the ecosystem 
> have been updated when we release a new Django version
>  3) to provide some guidance to the community that these are the packages 
> you should be paying attention to - the "first amongst equals" of the 
> broader third party app ecosystem.
>
> I know this isn't a small project. However, we have a good opportunity to 
> get the ball rolling next week :-)
>  
>

+1
 

-- 
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/790b2644-e0cd-4c98-be78-592b2ab078cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database-dependant tests and third-party backends

[Maximiliano Robaina]

El miércoles, 7 de mayo de 2014 14:18:25 UTC-3, Shai Berger escribió:
>
> Hi, 
>
> On Wednesday 07 May 2014 19:40:08 Aymeric Augustin wrote: 
> > 
> > I'm trying to make the lives of maintainers of third-party database 
> > backends a bit easier. 
> > 
>
> +1. 
>
> > 
> > *1) Checking database features* 
> > 
> > This is the correct solution for database-dependant tests in general. 
> > 
>
> In most cases, it is. But in some cases, you need to differentiate on 
> severely 
> idiosyncratic behaviors, which defy attempts to define them as anything 
> but 
> "behaves like MySql". 
>
> > *What do you think of adding feature flags that have the same value for 
> all 
> > core backends but may be set to a different value by third-party 
> backends?* 
> > 
> > With a comment explaining which backends use the flag and what it does, 
> I 
> > find it acceptable. Then we would skip some tests based on the flag. 
> > 
>
> Sounds good to me, 
>
> > *2) Checking connection.vendor* 
> > 
> > This is often inferior to feature flags. 
> > 
> > Positive checking ("run this test only for SQLite") is reasonable. At 
> > worst, the test is skipped on third-party databases where it could pass. 
> > 
> > Negative checking ("run this test on all databases except Oracle") is 
> more 
> > problematic. If a third-party backend also fails the test, there's no 
> easy 
> > way to ignore it. 
> > 
> > Conditional code ("do X for vendors A, B and C, do Y for other vendors") 
> is 
> > also problematic. All third-party backends will do Y, which may or may 
> not 
> > be the right behaviour. 
> > 
> > *Would you object to adding "microsoft" to explicit checks for 
> > connection.vendor where appropriate?* 
> > 
>
> That seems ugly to me, unless we actually add a core backend for SQL 
> Server. 
> It feels like adding a dependency on 3rd-party projects. 
>
> I suggest, instead, that we solve the problem for real (so even Firebird 
> can 
> enjoy it): Remove all vendor checks except for positive checking. Replace 
> conditional code with either conditions on feature flags, or refactoring 
> into 
> separate test functions; and replace negative checks by an API allowing 
> the 
> backends to filter the tests. So, instead of a test saying "I'm not 
> running on 
> Oracle", let Oracle say "I'm not running these tests". 
>
> This is much more work, but gives a much nicer result. Also, it should be 
> part 
> of the larger work -- a formal database backend API. 
>
>
I agree, I think this is much more cleaner approach.

Also, there are some specific features (at less in firebird), which cause 
test fail, for instance, test/regressiontests/model_fields/models.py, the 
BigD model max_digits 38 and decimal_places = 30 are not supported by 
firebird, 
So, how can I skip this test?  Would have to ask them to add one new 
database feature flag? I don't think that this be the correct approach.

-- 
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/8a752c74-1076-44c8-9a39-582ce05d78f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database-dependant tests and third-party backends

[Rahul]

I have created a ticket #22653 ( 
https://code.djangoproject.com/ticket/22653 ), for the issue I have 
mentioned. 

-- 
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/27af1382-aaca-4100-b8ad-fb8060f5cca9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Release of 1.7 news for podcast?

[Elena Williams]

Thank you thank you!

It's a massive release so I for one would much rather be sure and confident 
than rushed.

Thank you Tim and Andrew, and take care (I would recommend sunshine and 
sandy beaches ... bt ... )

Elena :)
@elequ

On Monday, May 19, 2014 4:57:59 AM UTC+8, Andrew Godwin wrote:
>
> Given that I'm still abroad at this point, I'm not as productive as I can 
> be at the moment for health reasons, and the number of release blockers 
> seems to keep growing, I wouldn't be able to put on a date on it. At least 
> a month at this point I suspect, but hopefully sooner.
>
> Andrew
>
>
> On Sun, May 18, 2014 at 6:11 PM, Tim Graham  > wrote:
>
>> You can use this link to see the current list of release blockers for 1.7:
>>
>>
>> https://code.djangoproject.com/query?status=assigned=new=!master=Release+blocker=id=summary=status=owner=type=component=changetime=1=changetime
>>
>> I would guesstimate we're at least a month out from 1.7 final since 
>> there's a minimum of 2 weeks after a release candidate is issued before 
>> final.
>>
>> Andrew may have some more concrete thoughts on how long the migrations 
>> release blockers might take to resolve.
>>
>>
>> On Saturday, May 17, 2014 11:29:38 PM UTC-4, Elena Williams wrote:
>>>
>>> (Don't want to pester anyone but ... )
>>>
>>> I was wondering if there's any updates about where the Django 1.7 
>>> release is at that I can put in to the podcast?
>>>
>>> Thanks!
>>> Elena :)
>>> @elequ
>>>
>>> ---
>>> References (nothing new on these):
>>> Roadmap: https://code.djangoproject.com/wiki/Version1.7Roadmap
>>> Release notes: https://docs.djangoproject.com/en/dev/releases/1.7/
>>>
>>  -- 
>> 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/e77d9800-bb57-4f4b-89aa-36d4c5eb6f6b%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-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/07818b0d-3b26-4353-94a3-99625553474c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.