Re: Pass Thru Image Proxy Patch Interest?

[Ed Menendez]

Agree on avoiding additional setting.

Re: cache
Basically if the file is not found locally then it goes out to the URL
to get it. So a local file couldn't be overwritten as that's the first
thing it checks. Cache is currently an option to the view too. Which
should be documented so it can be turned off if disk space is limited
locally.

Re: 1.2
No problem. Should I not even open a ticket with the patch until after
or is it OK to do now?


On Apr 14, 3:14 am, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:
> On Wed, Apr 14, 2010 at 10:42 AM, Ed Menendez <edmenen...@gmail.com> wrote:
> > Is there any interest in turning this into a patch for a new feature?
>
> >http://menendez.com/blog/using-django-as-pass-through-image-proxy/
>
> > It should only be used on dev servers but it really is a huge time
> > saver for developers vs rsync and since it keeps images locally it's a
> > better solution than prod images via S3.
>
> > It's 100% backward compatible and could be implemented with either a
> > settings and/or a change in the view parameter.
>
> >  (r'^(?P.*)$', 'static_fallback.serve', {'document_root' : '/
> > path/to/my/files/', 'fallback_static_url': 'http://myprodsite.com'})
>
> > or
>
> > FALLBACK_STATIC_URL = 'http://myprodsite.com'
>
> > If anyone think it's a good idea, let me know and I'll create a patch.
>
> Broadly speaking, yes, but:
>
>  * I'm not a fan of the separate FALLBACK_STATIC_URL setting. This
> isn't something that needs to be extraordinarily flexible - you're
> going to drop a static view in a DEBUG block in your urls.py for
> testing purposes, and you should be able to specify your fallback
> there.
>
>  * The caching behavior makes me a little nervous. I don't have any
> problems with the idea of falling back to a main image server, and the
> idea that those requests can be optimized sounds good; However, I'm
> concerned that users could get caught in a web of partially updated
> caches, or get into conflicts where a local file that a user is
> working with is overwritten by an enthusiastic downstream cache
> retrieval.
>
>  * That said, we're in the closing phases of getting Django 1.2 out
> the door, so now isn't the best time to propose or discuss new
> features. Once 1.2 is out, we'll open the floor for discussion of new
> proposals.
>
> 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-develop...@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.

Pass Thru Image Proxy Patch Interest?

[Ed Menendez]

Is there any interest in turning this into a patch for a new feature?

http://menendez.com/blog/using-django-as-pass-through-image-proxy/

It should only be used on dev servers but it really is a huge time
saver for developers vs rsync and since it keeps images locally it's a
better solution than prod images via S3.

It's 100% backward compatible and could be implemented with either a
settings and/or a change in the view parameter.

 (r'^(?P.*)$', 'static_fallback.serve', {'document_root' : '/
path/to/my/files/', 'fallback_static_url': 'http://myprodsite.com' })

or

FALLBACK_STATIC_URL = 'http://myprodsite.com'

If anyone think it's a good idea, let me know and I'll create a patch.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: DatabaseWrapper operators

[Ed Menendez]

It might be easier to write a manager depending on what exactly you're
trying to do. In my opinion you should write an operator for a
database feature that you're trying to implement but if you're trying
to cleanup text or transform text in some way... I think a manager
might be a better solution.

If the problem involves converting the text to the left side of the
equal sign (the table column).. then I would be careful you don't get
table scans all over the place.

On May 4, 5:26 am, pbzRPA  wrote:
> I would like to know if anyone knows how to create custom operators
> for querysets.
>
> Currently you can do something like:
>
> foo.objects.filter(myfield__icontains = x)
>
> I would like to add my own operator so I can do something like:
>
> foo.objects.filter(myfield__converttext = x)
>
> where "converttext" would be my own operator. Currently there a few
> operators in the django/db/backends/mysql/base.py:
>
> operators = {
>         'exact': '= %s',
>         'iexact': 'LIKE %s',
>         'contains': 'LIKE BINARY %s',
>         'icontains': 'LIKE %s',
>         'regex': 'REGEXP BINARY %s',
>         'iregex': 'REGEXP %s',
>         'gt': '> %s',
>         'gte': '>= %s',
>         'lt': '< %s',
>         'lte': '<= %s',
>         'startswith': 'LIKE BINARY %s',
>         'endswith': 'LIKE BINARY %s',
>         'istartswith': 'LIKE %s',
>         'iendswith': 'LIKE %s',
>     }
>
> I would like to add to this dict without modifying the django code.
>
> Any help would be appreciated.
--~--~-~--~~~---~--~~
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: Problem with too many indexes (SVN-7438) and (slightly) better index on auth_user?

[Ed Menendez]

But you would still need to pull the password from the table to do the
comparison in the "WHERE" clause. If you over-indexed and captured the
password as part of the index, the database only has to read the index
to figure if your row matches. This helps eliminate a read on a failed
login attempt (reducing locks, etc) and also would help on a
successful login attempt if you're only pulling out those two columns.
Django (I think?) pulls out all the columns so it probably needs to
read the table anyway on a successful attempt. Minor performance
enhancement for most sites but easy to implement.

The pk index problem is definitely a much bigger deal for those who
aren't going around pruning indexes.

On Apr 29, 9:24 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> +1 on pk index fix
>
> as for auth_user, username being indexed would be good, but I believe
> the hash is calculated completely outside of SQL, so there's no need
> to index password.
>
> On Apr 29, 12:15 pm, Ed Menendez <[EMAIL PROTECTED]> wrote:> When creating a 
> one to one table or a table with a compound key..
> > Django wants to create an index for the PK/alternate key and also
> > another index on the same column(s) because it's a FK. For example, if
> > I have:
>
> > class League(models.Model):
> > name= models.CharField(max_length=50)
>
> > class Season(models.Model):
> > name= models.CharField(max_length=50)
>
> > class LeagueSeason(models.Model):
> > league  = models.ForeignKey(League)
> > season  = models.ForeignKey(Season)
>
> > In LeagueSeason it will create the PK index on league + season (which
> > is correct), but then it will create an index on league and another on
> > season. The one on season should be created, but the one on league
> > should NOT be created since the PK index can be used. One to ones are
> > a simpler example and the 2nd index should never be created.
>
> > Better index on auth_user?
> > auth_user.username might as well have username and password in the
> > index since you usually query both and if you only query one, that's
> > ok, the index will still work. Since the typical use case for that is
> > login via username/pw, you never have to hit the table can just use
> > the index to pull the password. Saves an extra read to the database.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Problem with too many indexes (SVN-7438) and (slightly) better index on auth_user?

[Ed Menendez]

When creating a one to one table or a table with a compound key..
Django wants to create an index for the PK/alternate key and also
another index on the same column(s) because it's a FK. For example, if
I have:

class League(models.Model):
name= models.CharField(max_length=50)

class Season(models.Model):
name= models.CharField(max_length=50)

class LeagueSeason(models.Model):
league  = models.ForeignKey(League)
season  = models.ForeignKey(Season)

In LeagueSeason it will create the PK index on league + season (which
is correct), but then it will create an index on league and another on
season. The one on season should be created, but the one on league
should NOT be created since the PK index can be used. One to ones are
a simpler example and the 2nd index should never be created.

Better index on auth_user?
auth_user.username might as well have username and password in the
index since you usually query both and if you only query one, that's
ok, the index will still work. Since the typical use case for that is
login via username/pw, you never have to hit the table can just use
the index to pull the password. Saves an extra read to the database.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

django_session table

[Ed Menendez]

We might want to consider a performance boost for those that choose to
use the django_session table over memcached. If
django_session.session_data is made a char(40) instead of a
varchar(40) most DB engines will make that row a fixed length row
(longtext/blobs are stored outside the row with a pointer). If it's a
fixed length row, the DB can find the row much quicker since it can
just calculate the location. It's obviously not a critical fix, since
if you really wanted performance you would run it on memcached
instead, but still would be nice.

P.S. This is my first post in the group. Love Django!
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

American Idol game developed in Django

[Ed Menendez]

This was our first site in Django and also our intro to Python. We
used to play this on a spreadsheet with friends but were able to
develop the replacement in about a week with Django. Probably could
have been done much quicker if we weren't newbies to the framework.

http://aigame.digitalhaiku.com/

Special thanks to Eric Florenzano who gave us our introductory class
in Django. Hope this motivates some developers that are on the fence
on using Django.

- Ed

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---