Re: Long-term direction for shortcuts

[chairface]

On Aug 2, 9:50 pm, Jacob Kaplan-Moss  wrote:
> On Sun, Aug 2, 2009 at 8:05 PM, Brent Hagany wrote:
> > But, just to be explicit, I don't want to
> > limit the discussion just to that patch, or to render_to_response or
> > any particular shortcut.  First, we should discuss the larger issue of
> > whether technically unnecessary code (which is what any shortcut is)
> > should be allowed into Django, in my opinion.
>
> Well, discuss away... but I'm not going to put my foot in that one.
> Wide sweeping philosophy discussions aren't really much fun,
> especially when we're all just hand-waving anyway.
>
> Let me suggestion something different:
>
> 1. Propose a new shortcut function. Bonus points for a patch.
> 2. If it's full of win, it'll go in.
> 3. Rinse and repeat.
>
> I don't think anybody's opposed to the idea of "helpers" or
> "shortcuts," so just start making some suggestions. Either they'll
> turn out to be a good idea, or they won't. We don't need any larger
> framing device than that.
>

I am willing to do that - it was my impression that this wouldn't be
well-received on this list, since discussion belongs in the ticket.
Apologies if I misunderstood.

The patch/idea I'm putting forward is #10588.  It was closed as a
duplicate of mine (#9081), but Chris Cahoon prefers #10588 to mine,
which is fine with me.  The idea is simple - let render_to_response
return a status code other than 200.  The primary advantage this has
in my mind is that it provides a consistent shortcut-y way to return
responses, rather than using render_to_response in one view and a raw
HttpResponse subclass in another.  It lowers your cognitive overhead.

I am particularly curious to hear from you Jacob, as you originally
set #9081 to 'Accepted', and being rather naive, I kind of thought
that was it.  The pushback I've gotten on such a simple change has
surprised me.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Long-term direction for shortcuts

[Jacob Kaplan-Moss]

On Sun, Aug 2, 2009 at 8:05 PM, Brent Hagany wrote:
> But, just to be explicit, I don't want to
> limit the discussion just to that patch, or to render_to_response or
> any particular shortcut.  First, we should discuss the larger issue of
> whether technically unnecessary code (which is what any shortcut is)
> should be allowed into Django, in my opinion.

Well, discuss away... but I'm not going to put my foot in that one.
Wide sweeping philosophy discussions aren't really much fun,
especially when we're all just hand-waving anyway.

Let me suggestion something different:

1. Propose a new shortcut function. Bonus points for a patch.
2. If it's full of win, it'll go in.
3. Rinse and repeat.

I don't think anybody's opposed to the idea of "helpers" or
"shortcuts," so just start making some suggestions. Either they'll
turn out to be a good idea, or they won't. We don't need any larger
framing device than that.

Jacob

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Long-term direction for shortcuts

[chairface]

On Aug 2, 9:14 pm, Malcolm Tredinnick 
wrote:

> Simon has not justified why his particular preference for imports
> necessarily meets even the common case and why he, or somebody else,
> cannot put their own choices for common imports into a single that they
> import (pretty normal "reduce repetition" pattern in Python).

This is true.  This discussion is a chance for Simon or someone who
agrees with him to justify their position.  You are begging the
question.

> It's a source for ideas for further discussion with more details. A
> conference Q session lacks a *lot* of details.

Again, this discussion is a quest for more details.

> They are considered on a case-by-case basis, just like all proposed
> changes. This isn't new policy and I'm sure why it needs to be changed.

This is true as far as it goes, but it is not the whole story.  I am
certainly not asking for a change in policy.  This list discusses a
lot of things that have no code behind them yet, particularly in the
area of what features should be implemented.  This is the kind of
discussion I am asking for.  Is the feature of an expanded shortcuts
module worthwhile, and consistent with Django's goals?  I have seen
indications that opinion is split, and this is the place to discuss
such things.

> In the case of your proposed changes to render_to_response(), I see some
> added complexity that impacts everybody (maintainers, documentation
> readers and devs) for a small target userbase to do something that
> already only takes a single line (and if counting the imports really
> adds to your line count by a significant percentage, the code is so
> small that it's a tough push uphill to argue it's a common use-case --
> you import once and reuse often).

It is my contention that the added complexity is negligible such that
the word "complexity" does not even fit the situation.  But this is
the type of discussion that belongs in the ticket.  It's actually a
discussion we've already had.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Long-term direction for shortcuts

[Malcolm Tredinnick]

On Sun, 2009-08-02 at 18:53 -0700, chairface wrote:
> On Aug 2, 8:36 pm, Malcolm Tredinnick 
> wrote:
> > On Sun, 2009-08-02 at 18:05 -0700, Brent Hagany wrote:
> >
> > Putting too much weight on more or less throwaway comments in a single
> > video isn't going to be particularly useful.
> 
> They didn't seem to be "throwaway" to me - Simon had his requests
> prepared beforehand.  Also, it is only a single video, but that video
> is a pretty good resource for the topic of Django's future.  It was
> the topic of the entire hour.

Did you notice how all the answers were given in the space of an hour?
Good design thinking takes longer than that with careful consideration
of all sides. Once we add a feature we can *never* remove it.

Simon has not justified why his particular preference for imports
necessarily meets even the common case and why he, or somebody else,
cannot put their own choices for common imports into a single that they
import (pretty normal "reduce repetition" pattern in Python).

>   Are you implying that it's a poor
> source for people wondering where Django is going?  It was explicitly
> designed to be exactly that kind of source.

It's a source for ideas for further discussion with more details. A
conference Q session lacks a *lot* of details.

[...]
> The target is to get a clear read on whether patches to shortcuts are
> going to be considered, or dismissed by their nature.  

They are considered on a case-by-case basis, just like all proposed
changes. This isn't new policy and I'm sure why it needs to be changed.
In the case of your proposed changes to render_to_response(), I see some
added complexity that impacts everybody (maintainers, documentation
readers and devs) for a small target userbase to do something that
already only takes a single line (and if counting the imports really
adds to your line count by a significant percentage, the code is so
small that it's a tough push uphill to argue it's a common use-case --
you import once and reuse often).

> The objections
> I have received on my patches apply equally well to all shortcuts.

Yes, often they do. Which is why so many requests for enhancements
aren't added. Django would be about 2 million lines of code by now if we
accepted every request to add a second or third way to do something.

Regards,
Malcolm


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Long-term direction for shortcuts

[chairface]

On Aug 2, 8:36 pm, Malcolm Tredinnick 
wrote:
> On Sun, 2009-08-02 at 18:05 -0700, Brent Hagany wrote:
>
> Putting too much weight on more or less throwaway comments in a single
> video isn't going to be particularly useful.

They didn't seem to be "throwaway" to me - Simon had his requests
prepared beforehand.  Also, it is only a single video, but that video
is a pretty good resource for the topic of Django's future.  It was
the topic of the entire hour.  Are you implying that it's a poor
source for people wondering where Django is going?  It was explicitly
designed to be exactly that kind of source.

> Then there is no way the thread will ever result in a code change or
> even a resolution.

This thread, or the one in the ticket?

> No we shouldn't. This is entirely backwards. Under that logic, Django
> itself is pointless because it's already possible to do all that in
> Python. The point in that sentence is that a discussion without a target
> in mind is just an abstract philosophical discussion with no endgame in
> sight. It adds no value to the process of making a decision.

The target is to get a clear read on whether patches to shortcuts are
going to be considered, or dismissed by their nature.  The objections
I have received on my patches apply equally well to all shortcuts.  I
think that there is a difference in opinion and philosophy in the
community that has real effects on what goes into Django and what
doesn't.  Concretely, I have had the same ticket set to "Accepted" by
a core committer and then threatened to be wontfixed by another.  Is
it wrong for me to want clarification on this?

Futher, I simply do not understand how you can say that a question as
to what that philosophy is has no value in the decision making
process.  At the very least, it helps people to decide what they'll
submit patches for, and what they won't.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Long-term direction for shortcuts

[Malcolm Tredinnick]

On Sun, 2009-08-02 at 18:05 -0700, Brent Hagany wrote:
[...]
> If you watch the video, there was some disagreement with the idea
> right from the start.

Putting too much weight on more or less throwaway comments in a single
video isn't going to be particularly useful.

>   The ticket that grew out of that part of the
> discussion is #8950, and has been marked Someday/Maybe.  You may also
> want to reference #9081, where I have been discussing the issue with
> Chris Cahoon and Malcolm.  But, just to be explicit, I don't want to
> limit the discussion just to that patch, or to render_to_response or
> any particular shortcut.  

Then there is no way the thread will ever result in a code change or
even a resolution.

> First, we should discuss the larger issue of
> whether technically unnecessary code (which is what any shortcut is)
> should be allowed into Django, in my opinion.

No we shouldn't. This is entirely backwards. Under that logic, Django
itself is pointless because it's already possible to do all that in
Python. The point in that sentence is that a discussion without a target
in mind is just an abstract philosophical discussion with no endgame in
sight. It adds no value to the process of making a decision.

Regards,
Malcolm


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Long-term direction for shortcuts

[chairface]

Thanks Alex, I should have explicitly mentioned that rather than
letting the video take care of it.  I'm rather ambivalent on the
common import location myself, but I am in very in favor of his stated
reason for it: reducing the number of imports.  I think good shortcuts
can get us a lot of the way there.

On Aug 2, 8:27 pm, Alex Gaynor  wrote:
> On Sun, Aug 2, 2009 at 8:05 PM, Brent Hagany wrote:
>
> > Hello Django devs,
>
> > The issue of making shortcuts better (and decreasing the number of
> > imports in views.py files) was brought up at DjangoCon, and now that
> > 1.1 is out the door, I would like to spark some discussion on what
> > direction (if any) Django should take on the subject.  (Relevant video
> > here:http://www.youtube.com/watch?v=M1Qr9rSBGBE=PlayList=D415FAF...)
>
> > If you watch the video, there was some disagreement with the idea
> > right from the start.  The ticket that grew out of that part of the
> > discussion is #8950, and has been marked Someday/Maybe.  You may also
> > want to reference #9081, where I have been discussing the issue with
> > Chris Cahoon and Malcolm.  But, just to be explicit, I don't want to
> > limit the discussion just to that patch, or to render_to_response or
> > any particular shortcut.  First, we should discuss the larger issue of
> > whether technically unnecessary code (which is what any shortcut is)
> > should be allowed into Django, in my opinion.
>
> > I am in favor of expanding shortcuts, if it's not obvious already.
> > Now, somebody disagree!
>
> I don't have a problem with putting shortcut functions in, like the
> redirect one Jacob added for 1.1.  However I'm a massive -1 on adding
> a place for common imports like Simon proposed.  All that does is
> obscure the location of the source code by adding an extra layer of
> indirection.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Long-term direction for shortcuts

[Alex Gaynor]

On Sun, Aug 2, 2009 at 8:05 PM, Brent Hagany wrote:
>
> Hello Django devs,
>
> The issue of making shortcuts better (and decreasing the number of
> imports in views.py files) was brought up at DjangoCon, and now that
> 1.1 is out the door, I would like to spark some discussion on what
> direction (if any) Django should take on the subject.  (Relevant video
> here: 
> http://www.youtube.com/watch?v=M1Qr9rSBGBE=PlayList=D415FAF806EC47A1=2#t=36m15s)
>
> If you watch the video, there was some disagreement with the idea
> right from the start.  The ticket that grew out of that part of the
> discussion is #8950, and has been marked Someday/Maybe.  You may also
> want to reference #9081, where I have been discussing the issue with
> Chris Cahoon and Malcolm.  But, just to be explicit, I don't want to
> limit the discussion just to that patch, or to render_to_response or
> any particular shortcut.  First, we should discuss the larger issue of
> whether technically unnecessary code (which is what any shortcut is)
> should be allowed into Django, in my opinion.
>
> I am in favor of expanding shortcuts, if it's not obvious already.
> Now, somebody disagree!
> >
>

I don't have a problem with putting shortcut functions in, like the
redirect one Jacob added for 1.1.  However I'm a massive -1 on adding
a place for common imports like Simon proposed.  All that does is
obscure the location of the source code by adding an extra layer of
indirection.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Long-term direction for shortcuts

[Brent Hagany]

Hello Django devs,

The issue of making shortcuts better (and decreasing the number of
imports in views.py files) was brought up at DjangoCon, and now that
1.1 is out the door, I would like to spark some discussion on what
direction (if any) Django should take on the subject.  (Relevant video
here: 
http://www.youtube.com/watch?v=M1Qr9rSBGBE=PlayList=D415FAF806EC47A1=2#t=36m15s)

If you watch the video, there was some disagreement with the idea
right from the start.  The ticket that grew out of that part of the
discussion is #8950, and has been marked Someday/Maybe.  You may also
want to reference #9081, where I have been discussing the issue with
Chris Cahoon and Malcolm.  But, just to be explicit, I don't want to
limit the discussion just to that patch, or to render_to_response or
any particular shortcut.  First, we should discuss the larger issue of
whether technically unnecessary code (which is what any shortcut is)
should be allowed into Django, in my opinion.

I am in favor of expanding shortcuts, if it's not obvious already.
Now, somebody disagree!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Cache DB backend

[Leo Soto M.]

On Sun, Aug 2, 2009 at 11:41 AM, Fraser Nevett wrote:
[...]
> I won't spend any time on refactoring, but I have opened a ticket
> (#11623) and created a patch to ensure the table names get properly
> quoted in the SQL (which I think is a good idea, even if actually
> using the db cache isn't!).

If someone is going to commit fixes to the DB cache backend, please
also take a look at 
(which is causing failures with Jython backends).
-- 
Leo Soto M.
http://blog.leosoto.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: I need a pony: Model translations (aka "my proposal")

[David Danier]

> I don't research your idea deeply but for first look it seems very
> similar or same to django-multilingual.
> http://code.google.com/p/django-multilingual/

>From the database perspective it is similar, meaning it uses the same
database structure. What I tried to write down was mostly some usage and
API ideas to solve some things which pop up when using
django-multilingual and others:
 * Make it possible to use third party apps in i18n environments even if
the app was not designed to do this (This idea was stolen from
pluggable-model-i18n.)
 * Don't add to much overhead for db performance and others (One JOIN,
nothing more, this JOIN should be transparent to the user. This idea was
stolen from model inheritance.)
 * Support getting results if no translation is available (sometimes you
don't need to have a translation, for example if all fields are
optional. This is possible in most model translation projects, even if
it involves hammering the database with extra queries for each
translation there. Conditional JOIN solves this in my proposal.)

In conclusion I try to use the database structure django-multilingual
proposes (which should be the best for the job anyway), keep usage as
simple as using model inheritance (keep working with translations as
simple as possible) while using a register approach to keep this
application independent (thats some kind of killer feature).

Hope this helps to see the differences here. Perhaps the file I attached
helps to see some usage examples.

One big advantage of my proposal over any existing solution is the
possibility to use third party apps without changing their code. I still
think this is very important as developers should not need to worry
about internationalization when writing third party apps, because you
should not need to use some complex database layout if you don't need
translations.

pluggable-model-i18n solves this, too, but it has some
limitations/flaws. Using the pluggable-model-i18n you cannot optimize
the SQL query when using translations and you run into many choices
where to find a value, which are most significant if you want to query
your database by some translated field (slug is translated:
Book.objects.get(slug=...) vs. Book.objects.get(translation__slug=...,
translation__language=...)). This are the two most significant
disadvantages, others might appear when using pluggable-model-i18n in a
productive environment.

Greetings, David Danier

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Cache DB backend

[Fraser Nevett]

On Aug 2, 2:48 pm, Russell Keith-Magee  wrote:
> On Sat, Aug 1, 2009 at 6:06 PM, Fraser  Nevett wrote:
>
> > I was looking at the database cache backend and noticed a number of of
> > things that might be worth improving...
>
> >  * The "createcachetable" management command manually constructs and
> > executes SQL to create the table. This is seems a bit undesirable as
> > we already have a well-established and well-tested ORM for the
> > management of creating tables. It also seems a bit untidy to have the
> > definition of the database table in a completely separate part of the
> > codebase from the rest of the db cache code.
>
> >  * The db backend code manually constructs and executes SQL to read
> > from and write to the cache table. Looking through that code, the
> > table name doesn't get escaped when put into the SQL and the expiry
> > timestamp doesn't get properly pre-processed before insertion (see
> > #11483).
>
> > I'm posting here first rather than opening a ticket to find out
> > whether there was a deliberate design decision made for any of this.
> > Is there any reason the cache table is not just a standard Model?
>
> > Using a Model and the ORM would resolve some of the issues I've listed
> > above and seems to be good DRY with respect to writing SQL. It would
> > require an app to be added to INSTALLED_APPS if the db cache was being
> > used, though I'm not sure that's a big issue.
>
> > There is a little complexity surrounding the name of the table, as at
> > present this gets set in CACHE_BACKEND (or as an argument to the
> > createcachetable management command), so the model would have to
> > somehow set its db_table meta data from this. We could actually
> > possibly get rid of createcachetable altogether and just leave the
> > table creation to syncdb.
>
> > By switching to using a standard Model, we would also get the benefit
> > of the multi-db support that's currently being worked on. This would
> > allow the db cache to run of an entirely separate database, if
> > required.
>
> > Could I please get some feedback on the above and as to whether a
> > refactor of this part of the code as described would be a worthwhile
> > exercise?
>
> There are a couple of answers to your "why is it so" query.
>
> One reason we don't use a standard Django model for the cache backend
> is that the only cache backend that would use the table is the
> database backend. Django doesn't have 'optional' tables - you includes
> the app, you gets the tables. If you're using dummy, locmem,
> memcached, file, or any other custom backend, you would end up with
> empty tables serving no purpose in your database. Ok, there isn't
> really any overhead to an empty table, and you don't have to add the
> cache app to your INSTALLED_APPS if you're not using the database
> backend. However, it's just as easy to write and document the use of a
> one-shot management command.
>
> A second reason is that when you're talking about caching, you're
> implicitly talking about optimal performance, so you need to get
> everything out of the way that could impede that performance. Django's
> ORM doesn't have a huge overhead, but it does have _some_ overhead.
> Given that a caching query is such a simple beast, writing it using
> the ORM rather than raw queries doesn't really yield you much
> advantage in terms of implementation simplicity, but it does slow down
> an operation that, by definition, is supposed to be as fast as
> possible.
>
> Lastly, and perhaps most importantly, if you're using the database
> backend for anything other that amusement purposes, UR DOING IT WRONG
> :-). The database backend is an interesting novelty and a way to
> demonstrate the flexibility of the caching backend, but it really
> shouldn't be confused as a good idea. One of the major goals of
> caching is to reduce database load, and you don't reduce load by
> adding extra reads and writes to the database. If your site needs
> caching, use memcached. No ifs, no buts. Just use memcached. When
> you're doing local testing, locmem and file are decent substitutes,
> and dummy is helpful when you are debugging, but memcached is where
> the serious money is.
>
> In summary - I'm sure there are ways that the implementation of the
> database cache backend could be improved, but in all honesty, the best
> refactoring would be an rm -rf :-)
>
> Yours,
> Russ Magee %-)

Hi Russ,

Thanks for your reply. I understand and completely agree with what
you're saying, especially with regards to using a database as a cache
backend.

I won't spend any time on refactoring, but I have opened a ticket
(#11623) and created a patch to ensure the table names get properly
quoted in the SQL (which I think is a good idea, even if actually
using the db cache isn't!).

Fraser
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To 

Re: Cache DB backend

[Russell Keith-Magee]

On Sat, Aug 1, 2009 at 6:06 PM, Fraser  Nevett wrote:
>
> I was looking at the database cache backend and noticed a number of of
> things that might be worth improving...
>
>  * The "createcachetable" management command manually constructs and
> executes SQL to create the table. This is seems a bit undesirable as
> we already have a well-established and well-tested ORM for the
> management of creating tables. It also seems a bit untidy to have the
> definition of the database table in a completely separate part of the
> codebase from the rest of the db cache code.
>
>  * The db backend code manually constructs and executes SQL to read
> from and write to the cache table. Looking through that code, the
> table name doesn't get escaped when put into the SQL and the expiry
> timestamp doesn't get properly pre-processed before insertion (see
> #11483).
>
> I'm posting here first rather than opening a ticket to find out
> whether there was a deliberate design decision made for any of this.
> Is there any reason the cache table is not just a standard Model?
>
> Using a Model and the ORM would resolve some of the issues I've listed
> above and seems to be good DRY with respect to writing SQL. It would
> require an app to be added to INSTALLED_APPS if the db cache was being
> used, though I'm not sure that's a big issue.
>
> There is a little complexity surrounding the name of the table, as at
> present this gets set in CACHE_BACKEND (or as an argument to the
> createcachetable management command), so the model would have to
> somehow set its db_table meta data from this. We could actually
> possibly get rid of createcachetable altogether and just leave the
> table creation to syncdb.
>
> By switching to using a standard Model, we would also get the benefit
> of the multi-db support that's currently being worked on. This would
> allow the db cache to run of an entirely separate database, if
> required.
>
> Could I please get some feedback on the above and as to whether a
> refactor of this part of the code as described would be a worthwhile
> exercise?

There are a couple of answers to your "why is it so" query.

One reason we don't use a standard Django model for the cache backend
is that the only cache backend that would use the table is the
database backend. Django doesn't have 'optional' tables - you includes
the app, you gets the tables. If you're using dummy, locmem,
memcached, file, or any other custom backend, you would end up with
empty tables serving no purpose in your database. Ok, there isn't
really any overhead to an empty table, and you don't have to add the
cache app to your INSTALLED_APPS if you're not using the database
backend. However, it's just as easy to write and document the use of a
one-shot management command.

A second reason is that when you're talking about caching, you're
implicitly talking about optimal performance, so you need to get
everything out of the way that could impede that performance. Django's
ORM doesn't have a huge overhead, but it does have _some_ overhead.
Given that a caching query is such a simple beast, writing it using
the ORM rather than raw queries doesn't really yield you much
advantage in terms of implementation simplicity, but it does slow down
an operation that, by definition, is supposed to be as fast as
possible.

Lastly, and perhaps most importantly, if you're using the database
backend for anything other that amusement purposes, UR DOING IT WRONG
:-). The database backend is an interesting novelty and a way to
demonstrate the flexibility of the caching backend, but it really
shouldn't be confused as a good idea. One of the major goals of
caching is to reduce database load, and you don't reduce load by
adding extra reads and writes to the database. If your site needs
caching, use memcached. No ifs, no buts. Just use memcached. When
you're doing local testing, locmem and file are decent substitutes,
and dummy is helpful when you are debugging, but memcached is where
the serious money is.

In summary - I'm sure there are ways that the implementation of the
database cache backend could be improved, but in all honesty, the best
refactoring would be an rm -rf :-)

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---