Re: base implementations of natural key methods

[Jian Li]

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; it returns a tuple containing *all*
non-auto-generated unique fields.

3) In the presence of multiple `unique_together` tuples, the implementation
arbitrarily chooses the first one.

4) In the presence of both `unique_together` fields and `unique` fields,
the implementation arbitrarily goes with the former.

You can see the specific algorithm at line
1422
.

The implementation always chooses a natural key which uniquely identifies
the relevant model. The choice may be arbitrary in the presence of multiple
cues, but so is any individually-implemented choice of a natural key.

At the very worst, if the user does not agree with the choice for the
specific model, they can fall back to individually implementing the natural
key for that model; this is no worse than the current situation. So I would
argue that the base implementation proposed here is strictly better than
the status quo.

In the course of serializing about a dozen different models, I've found
this to be a very useful base implementation that has saved me from the
tedium of writing many lines of boilerplate.


On Thu, May 8, 2014 at 10:07 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> 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 each model, I've written a patch that implements the
>> relevant logic on the model and manager base classes:
>>
>>
>> https://github.com/jianli/django/compare/default-natural-key-implementation
>>
>> https://github.com/jianli/django/commit/b6d644b45c379cae83f7f2609525e616b62ade52
>>
>>
>> Details:
>>
>> - The proposed implementation is recursive, which enables it to create
>> natural foreign keys even when the foreign key structure is arbitrarily
>> deep.
>>
>> - When a natural key is not available but the user specifies
>> `--natural-foreign`, the proposed implementation will raise an exception.
>> This is inconsistent with the current behavior of silently falling back to
>> using the "artificial" foreign key. However, I would argue that this is the
>> correct behavior, and also the behavior implied by the documentation; if
>> the user wants a natural foreign key serialization and Django is not able
>> to provide it, Django should let the user know with an exception.
>>
>> - I was unsure whether to add the model method to `ModelBase` or `Model`.
>>
>> - I've manually tested a nearly identical patch against 1.5.4, but
>> haven't had a chance to test against the development version.
>>
>> Please let me know what you think, and keep up the amazing work!
>>
>
> Hi Jian,
>
> What you've proposed is an interesting idea, and a magnificent example of
> what you can do by exploiting the contents of _meta - but as a proposal for
> Django's core, I think it falls down in a couple of critical places.
>
> 1) A model without unique_together can still implement natural key. For
> example, the User model has a natural key, but doesn't have a
> unique_together clause. So, if you've just go a unique field, you can still
> have a natural key, but this helper won't help.
>
> 2) Assuming you can resolve (1) (which wouldn't be that hard in practice),
> multiple fields on a model can have unique=True set. How do you pick which
> one is *really* the natural key?
>
> 3) A model can have *multiple* unique_together clauses. Your code only
> appears to handle the case of "unique_together = ('field1','field2')", but
> it's also legitimate to say "unique_together = [('field1', 'field2'),
> ('field1', 'field3')]" - i.e., multiple independent unique_together
> clauses. Again, how do you pick which one is *really* the natural key?
>
> 4) What about if you have multiple fields with unique=True *and* multiple
> unique_together clauses?
>
> 5) Even if we could resolve those issues, there's a backwards
> compatibility issue implicit in changing behaviour around serialisation,
> and Django (as a project) is very sensitive to those issues.
>
> There *might* be a solution that covers problems 1-4, and maybe even
> problem 5; but that solution is almost certainly going to be declarative
> (i.e., naming which field/field pair is the natural key). However, once
> you're declaring the fields that are your natural key, you're 90% of the
> way to an implementation of get_natural_key() -- so you have to ask why
> bother developing and maintaining a moderately 

Re: Database-dependant tests and third-party backends

[Russell Keith-Magee]

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 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 :-)

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

Re: base implementations of natural key methods

[Russell Keith-Magee]

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 each model, I've written a patch that implements the
> relevant logic on the model and manager base classes:
>
> https://github.com/jianli/django/compare/default-natural-key-implementation
>
> https://github.com/jianli/django/commit/b6d644b45c379cae83f7f2609525e616b62ade52
>
>
> Details:
>
> - The proposed implementation is recursive, which enables it to create
> natural foreign keys even when the foreign key structure is arbitrarily
> deep.
>
> - When a natural key is not available but the user specifies
> `--natural-foreign`, the proposed implementation will raise an exception.
> This is inconsistent with the current behavior of silently falling back to
> using the "artificial" foreign key. However, I would argue that this is the
> correct behavior, and also the behavior implied by the documentation; if
> the user wants a natural foreign key serialization and Django is not able
> to provide it, Django should let the user know with an exception.
>
> - I was unsure whether to add the model method to `ModelBase` or `Model`.
>
> - I've manually tested a nearly identical patch against 1.5.4, but haven't
> had a chance to test against the development version.
>
> Please let me know what you think, and keep up the amazing work!
>

Hi Jian,

What you've proposed is an interesting idea, and a magnificent example of
what you can do by exploiting the contents of _meta - but as a proposal for
Django's core, I think it falls down in a couple of critical places.

1) A model without unique_together can still implement natural key. For
example, the User model has a natural key, but doesn't have a
unique_together clause. So, if you've just go a unique field, you can still
have a natural key, but this helper won't help.

2) Assuming you can resolve (1) (which wouldn't be that hard in practice),
multiple fields on a model can have unique=True set. How do you pick which
one is *really* the natural key?

3) A model can have *multiple* unique_together clauses. Your code only
appears to handle the case of "unique_together = ('field1','field2')", but
it's also legitimate to say "unique_together = [('field1', 'field2'),
('field1', 'field3')]" - i.e., multiple independent unique_together
clauses. Again, how do you pick which one is *really* the natural key?

4) What about if you have multiple fields with unique=True *and* multiple
unique_together clauses?

5) Even if we could resolve those issues, there's a backwards compatibility
issue implicit in changing behaviour around serialisation, and Django (as a
project) is very sensitive to those issues.

There *might* be a solution that covers problems 1-4, and maybe even
problem 5; but that solution is almost certainly going to be declarative
(i.e., naming which field/field pair is the natural key). However, once
you're declaring the fields that are your natural key, you're 90% of the
way to an implementation of get_natural_key() -- so you have to ask why
bother developing and maintaining a moderately complex automated method for
something that isn't that hard to declare explicitly in 2 lines of code.

So, I'm -0 on this as currently proposed. If you've got any creative
solutions to these problems, please raise them. The broader principle of
having models have useful properties by virtue of their basic definition is
appealing to me. I'm just not convinced that based on the details you've
presented so far, we would get a net gain.

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

Re: Database-dependant tests and third-party backends

[Aymeric Augustin]

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 Augustin  
wrote:

> 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 copy of the tests for each backend -- that would 
> be a positive vendor check -- and to adjust them every time. This would cause 
> some duplication, but that isn't a big deal in test code.
> 
> Backend-specific tests are an interesting idea but I'd like to keep them out 
> of the scope of this discussion, if possible ;-)
> 
> -- 
> Aymeric.
> 

-- 
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/05938D5C-C6C2-44CE-ADB3-C55AA2386D1C%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Database-dependant tests and third-party backends

[Aymeric Augustin]

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 copy of the tests for each backend -- that would be a positive 
vendor check -- and to adjust them every time. This would cause some 
duplication, but that isn't a big deal in test code.

Backend-specific tests are an interesting idea but I'd like to keep them out of 
the scope of this discussion, if possible ;-)

-- 
Aymeric.

-- 
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/95F11A45-5B95-48DE-A11E-8B813B1B5D94%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Database-dependant tests and third-party backends

[Michael Manfre]

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 differentiate on
> severely
> idiosyncratic behaviors, which defy attempts to define them as anything but
> "behaves like MySql".
>

There are times when it makes sense to have tests that are run only for a
specific backend without being controlled by a database feature. These
tests shouldn't intermingle with the rest of the test suite. More on this
below.


> > *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.
>

This would make me very happy. It provides backends with a much cleaner way
of supporting/testing different database versions and/or drivers.


> > *2) Checking connection.vendor*
> >
> > *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.
>

As a blanket statement, I object to explicit vendor checks. Adding
"microsoft" would help me, as shown by Aymeric's linked example to my
Django 1.6 branch commit, but it is not the correct approach. Django needs
more of
https://github.com/django/django/commit/c89d80e2cc9bf1f401aa3af4047bdc6f3dc5bfa4


> I suggest, instead, that we solve the problem for real (so even Firebird
> can
> enjoy it): Remove all vendor checks except for positive checking.


A positive vendor check should be shunned like global variables and used
only when there is no other choice.


> Replace conditional code with either conditions on feature flags, or
> refactoring into
> separate test functions;


A conditional feature check is better for test speed and code maintenance.


>  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".
>

It would be better if a database backend could provide extra tests that it
would expose to Django that can be run with the rest of the test suite. If
the backend is used, then the test runner would find its tests and run them
if specified, or part of the "run everything" default. This would make the
test suite cleaner in general and also solve the awkwardness I face with
trying to run my positive vendor check tests.

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

Re: Database-dependant tests and third-party backends

[Aymeric Augustin]

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 them as anything but
> "behaves like MySql".
>

Yes, that's the (only) appropriate use case for connection.vendor checks.

> *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.
>

It isn't exactly a dependency, but I see what you mean.


> 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".
>

Yes, that's the best solution. I'll audit connection.vendor checks and see
how
many flags we need to introduce.

-- 
Aymeric.

PS: while we're there, we could also audit feature flags and deprecate
obsolete ones, like those for versions of SQLite from 10 years ago.

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

Re: Database-dependant tests and third-party backends

[Shai Berger]

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.

My 2 cents,

Shai.

-- 
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/201405072018.26146.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Database-dependant tests and third-party backends

[Aymeric Augustin]

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

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

For an example, see
https://github.com/manfre/django/commit/8a9c31caaac30b1462481ecdb028f31c4db44375

Of cours, if that becomes too complicated to manage, that means we should
switch to a feature flag ;-)

Thanks for your feedback,

-- 
Aymeric.

-- 
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/CANE-7mVLHSpC3ZVBacBs_u0-rLDUogYFjtcy2FY3q_--kPes2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature request: ttl method for cache

[Piotr Gosławski]

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 Apolloner 
> > napisał: 
> > > 
> > > [...] 
> > > Memcached doesn't provide access to the remaining TTL, and I don't see 
> how 
> > > we can reasonably fake this without writing an extra key containing 
> the 
> > > expiration date. 
> > > 
> > >  Would that be unacceptable to add a switch in backend settings and 
> also 
> > as extra argument for set() that would cause django to transparently 
> save 
> > ttl as an extra key? It would obviously be disabled by default and docs 
> > would say about the extra memory this feature needs. 
>
> 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, giving you 
> the 
> information you need. 
>
> -Thomas 
>
> > 
> > -- 
> > 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/913011d8-f4c4-4e7c-ac8f-6aa85869e669%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
> -- 
> mvh 
> Thomas Kongevold Adamcik 
>

-- 
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/06af0d07-d328-4f31-9582-f4f5a6f3d139%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature request: ttl method for cache

[Piotr Gosławski]

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, giving you 
> the 
> information you need. 
>
> -Thomas 
>
>  
I would sacrifice atomicity of incr()/decr() methods and hit their 
performance pretty hard.

-- 
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/3e26c0b8-ab60-41b2-aa2d-2c2edc47e9b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.