Hi Russ,
Thanks for the feedback!
I believe the proposed code already addresses points 1-4.
1) The implementation does in fact return the correct natural key,
`(self.username,)`, for the User model.
2) When multiple fields have `unique=True`, the implementation does not
choose from among them;
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
On Wed, May 7, 2014 at 10:20 AM, Jian Li wrote:
> Hi!
>
> In the course of implementing `natural_key` for many different models,
> I've noticed that the implementation is fairly predictable; it tends to use
> the fields already marked as unique. To avoid writing a separate
> implementation for ea
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
It would sacrifice atomicity of incr()/decr() methods and hit their speed
pretty hard.
W dniu wtorek, 6 maja 2014 16:47:53 UTC+2 użytkownik adamcik napisał:
>
> On Tue, May 06, 2014 at 05:57:28AM -0700, Piotr Gosławski wrote:
> > W dniu wtorek, 6 maja 2014 11:47:17 UTC+2 użytkownik Florian Apoll
W dniu wtorek, 6 maja 2014 16:47:53 UTC+2 użytkownik adamcik napisał:
>
> See
> https://groups.google.com/d/msg/django-developers/ctKJzBTONu8/opbWqUIcOKgJ
> for a similar case that has come up before. The tuple solution used there
> could easily be adapted to store the time the key will expire,
11 matches
Mail list logo
