Use other Backend if Redis isn't available

[rafaelcapucho]

Use other Backend if Redis isn't available

[niwinz]

Interesting approach! I had not thought of that, but it may be interesting. Especially to prevent the application to stop working in a maintenance reboot of redis.

Although not entirely clear to me, at what level do.
If done more by django, the current implementation has to be modified considerably. And I doubt that these changes would accept the core of django.
Another option, would do on a "django-redis". But other questions go here:
If the redis server falls automatically fallback to db, but when and how I have to decide to return to redis on this goes up? These constants checks can add a significant overhead.

Have a suggestion about this?

It's a very interesting feature, but needs design decisions to implement it well.

[rafaelcapucho]

Hello Fellow,

I guess that you got the idea, the cache should operate just like a plus not something that blocks.

And for sure we have some big design decisions here, can you throw to defaults backends inside django-redis when you catch the redis connection exception, in other words you can pass to others backends, in that case django-redis will operate just like a proxy until the Redis Server get up?

We can create some filters system, exemple.. the request number 1 try to use Redis and get bad results then our filter system get that behavior and start to pass directly to the second backend, in order. We can defined some Ratio, to not try to connect in Redis Server for each request, but using that Ratio, for example 1 test for each 30 requests (using counting). When we receive that Redis Server in on so our filter are free.

The question, throwing to other backends that was previously defined inside settings.CACHES is easy? cosidering that these backends are already implemented inside Django..

may it's the first step to think about..

any idea?

Cya!

[rafaelcapucho]

Look at this Andrey:

https://code.djangoproject.com/ticket/16006

Cya!

[niwinz]

Okay, I agree that the cache has to be an addon, not something blocking.
I had an idea similar to yours but the concept of the counter was not in my mind.

Another feature I want is to implement master-slave connection and I have to see how to implement this feature you propose.

I do a refactor the code to make the connection to be lazy redis. Among other things. So for a major release (3.0)

I will start working on it one of these days, as have some time.

[rafaelcapucho]

Andrey, Are you considering the implementation of that (optional) function system that is called when the system detect that the Redis Server is off?

It's very important i guess because can implement notices to someone (maybe email) about the situation, the implementation of that function should be by the user.

hugs..

[niwinz]

I'm not moving on this issue because of my limited time. Right out while I wear with this.

I mention this so you know I have not been forgotten this feature;)

[niwinz]

Now, experimental fallback switching feature added on branch feature/master-slave: 5ec9658

Among other things, has been refactored all the code and add support for Master-Slave setup.

[rafaelcapucho]

Hello Niwibe,

Sorry i'm late,

I tried 5ec9658, but i'm getting:

that error: http://i.imgur.com/ckEok.jpg

You have already plans to merge with main branch?

thank you for your effort!

[niwinz]

Sorry to keep you waiting so long. I was pretty busy with other things.
The error it gives is due to a failure very silly and others are caused by that bad you should have the format of the connection string.

I made ​​small changes to the last commit. Pass all tests (no shard).

Andrey

[niwinz]

It still implemented with slighty different approach on failover experimental client (now merged to master).
I don't have mucho time for this feature. But all improvements are welcome.

And... Sorry for my very late reply.