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
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.
>>
>
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 fea
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 em
Hi Rahul,
Can you open a ticket for these specific issues. Thanks a lot for the
feedback!
Marc
On 11 May 2014 20:07, Rahul wrote:
> Hi,
> I am maintaining DB2 backend and facing same problem, there is need to
> change as much as we can change vendor depended check to features depended
> test
Hi,
I am maintaining DB2 backend and facing same problem, there is need to
change as much as we can change vendor depended check to features depended
test.
some of test cases written with keeping some features of backend in mind
but they didn't have putted the feature check there.
Following t
On Thu, May 8, 2014 at 12:40 AM, Aymeric Augustin <
aymeric.augus...@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 MS
Finally I bit the bullet and added half a dozen flags just for introspection
capabilities. The pull request is ready for review.
I don't think remaining vendor checks will hurt third-party backends. We can
continue this effort if they do.
--
Aymeric.
On 7 mai 2014, at 22:20, Aymeric Augusti
I've created a pull request: https://github.com/django/django/pull/2640. It
removes almost all non-positive vendor checks.
I didn't deal with all introspection tests because there's too much variability
between backends to express with feature flags. I'm wondering if the solution
is to create a
On Wed, May 7, 2014 at 1:18 PM, Shai Berger wrote:
> Hi,
>
> On Wednesday 07 May 2014 19:40:08 Aymeric Augustin wrote:
>
> *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 dif
2014-05-07 19:18 GMT+02:00 Shai Berger :
> > *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
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
Hello,
I'm trying to make the lives of maintainers of third-party database
backends a bit easier.
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
13 matches
Mail list logo
