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.
