Re: memcached-based-cache - timeout=0 does not work as intended by memcached
On Jul 26, 10:02 am, Tobias McNulty wrote: > If such reusable code needs to cache things forever, which sounds perfectly > reasonable to me, I'd still rather not co-opt "0" to mean "forever" in all > cases. Each backend that supports caching with no timeout could easily > offer a class attribute, such as "TIMEOUT_FOREVER", that indicated how to > set the timeout in these cases. I'm not sure I see the problem with co-opting 0, since it already has (or should have) that meaning on the most commonly-used backend, and doesn't really have any other sensible meaning as a cache timeout value. But the proposed class attribute is fine too. > Rejecting a particular subset of cache keys is also not the greatest analogy > to co-opting configuration values. :-) The common thread, of course, is making it possible to write reusable caching code without special-casing particular backends. Carl -- 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.
Ticket #14007: Automatically discover models within a package without using the app_label Meta attribute
Hi, I've added a ticket with a patch for automatically discovering models within a package without using the app_label Meta attribute. An old and somewhat related ticket is: http://code.djangoproject.com/ticket/2289/. This addition is relatively small code-wise, but it does add a new feature to the framework. Instead of "looking one level up" from the module a model is defined in the new code looks one level up from the module/package named "models" and then falls back to the existing behavior of simply "looking one level up" if no such module/package exists. I've added examples of the new functionality to the existing comments in the code: For 'django.contrib.sites.models', one level up would be 'sites'. For 'geo.models.places' it would be 'geo'. For 'polymorphic.polymorhpic_model' it would be 'polymorphic'. I've also copied and slightly modified the existing model_package model tests to cover the new code. This addition is very intuitive IMO, and it definitely cuts down on the overhead incurred when making the design decision to group models into a package. I certainly find it useful. Per the Django contributor guidelines I'm asking for guidance about whether this patch is considered non-trivial. Any feedback is appreciated. Thanks, - Mark http://code.djangoproject.com/ticket/14007 -- 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.
[gsoc2010/app-loading] update
Hey there,
sorry for not posting an update in such a long time. The hardest part of the
refactoring so far was keeping backwards compatibility. So while the internals
of the appcache changed, the functionality remained the same. Ayway, the
interesting stuff is still coming up. So there aren't any new exciting features
to try out yet. I met Jannis at EuroPython in Birmingham last week and we got
to discuss some things. Here's a list of remaining TODO's:
* Task: Loading custom App classes
In its current state, the AppCache creates a generic App class for every entry
in settings.INSTALLED_APPS. But in order to allow packages to modify specific
attributes of this class, it should be possible for a package to ship with
their own App class (which is a subclass of django.core.app.App).
To realize this, an entry in settings.INSTALLED_APPS can be the dotted path
to the App class of a package. For example:
INSTALLED_APPS = ('foobar.FooApplication',)
The AppCache will go through the INSTALLED_APPS and instanciate generic App
classes (for entries that don't point to App classes) and custom App classes
(for those entries that point to an subclass of App).
* Task: Create (custom) App instances for dependencies
If a model from contrib.auth uses a model from another package such as
contrib.contenttypes, the ModelBase will trigger the registration for both
models. This means that there need to be App instances (or custom app
instances) created for these dependencies. This is already partly implemented
as there are generic App classes instanciated.
The problem with this task is that the register_models function from the
AppCache only gets passed the app_label. Which makes it impossible to load
custom app classes. The solution for this problem would be to use the full
qualified name internally in the AppCache, but let methods like get_models,
get_model etc. still work with only the app_label for backwards-compatibility.
This also involves throwing Exceptions when a developer tries to install
two apps that have the same app_label.
* Task: Add verbose_name to the App class
Each App class will have the possibility of setting a
verbose_name/verbose_name_plural attribute. This attribute will be a string
and translateable via gettext. Currently the app_label is used as a, non
translateable, title (as there is no notation of an "application" in django).
This means that for example for the django.contrib.auth package, "auth" would
be the title in the contrib.admin index. However, it would be better for this
to be "Authentication" or "Authentifizierung" in german. To demonstrate this
new attribute, the admin will need to be modified.
* Task: Add db_prefix to the App class
Beside the verbose_name attribute, there will also be a db_prefix attribute.
This attribute will allow users to specifiy a prefix value for the database
tables. Currently, the app_label is used for this. So, for example, tables
for the models in django.contrib.auth will be created under auth_.
There is no way of modifying the name. For this, the ORM needs to be modified
to use the app.db_prefix instead of the models app_label.
* Task: Move django.db.loading to django.core.app
The current model loading core lives in django.db.loading. However, since the
code will be refactored to also allow packages without models it won't
make any sense to let it live in django.db.loading.
* Task: Add Signals
Add signals to the AppCache, so that developers can modify parts of the stages
of the AppCache without monkey patching or replacing it.
Arthur
--
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: firebird backend for django
Hi,
I've opened a ticket for months ago -
http://code.djangoproject.com/ticket/13159.
Only needs a test case.
David Elias
On Jul 23, 10:30 pm, maxi wrote:
> Hi,
>
> I'm working on django-firebird project and doing some modifications
> for work with django 1.2
> Right now, I'm trying to pass some tests running the tests suit of
> django trunk code and I found the next problem:
>
> django is trying to execute this sql:
>
> SELECT "AGGREGATION_BOOK"."PRICE", COUNT("AGGREGATION_BOOK"."PRICE")
> AS "COUNT"
> FROM "AGGREGATION_BOOK"
> GROUP BY "AGGREGATION_BOOK"."PRICE"
> ORDER BY count DESC, "AGGREGATION_BOOK"."PRICE" ASC
>
> But, I get the next error:
>
> DatabaseError: (-104, 'isc_dsql_prepare: \n Dynamic SQL Error\n SQL
> error code = -104\n Token unknown - line 1, column 157\n DESC --
> SELECT "AGGREGATION_BOOK"."PRICE", COUNT("AGGREGATION_BOOK"."PRICE")
> AS "COUNT" FROM "AGGREGATION_BOOK" GROUP BY "AGGREGATION_BOOK"."PRICE"
> ORDER BY count DESC, "AGGREGATION_BOOK"."PRICE" ASC')
>
> The problem is with the count field on ORDER BY clause. The sql is
> defined as COUNT("AGGREGATION_BOOK"."PRICE") AS "COUNT" and the
> count field is upper case (and quoted) then the order by clause must
> be:
>
> ORDER BY "COUNT" DESC
>
> Which method can I override to solve this?
> Any help?
>
> Thanks in advance.
>
> Maxi.
--
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: memcached-based-cache - timeout=0 does not work as intended by memcached
On Jul 27, 9:22 pm, Carl Meyer wrote: > The common thread, of course, is making it possible to write reusable > caching code without special-casing particular backends. I agree with Carl. We have an abstracted api - having a property with different meanings for different backends makes things a lot less pluggable. -- 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.
How to post data to the admin form by urllib2 ?
Hi:
I build a website and want to login the admin form by python code. I
have disabled the CSRF in my project and use urllib2 to post data.
here are my codes:
import urllib
import urllib2
import cookielib
cj = cookielib.CookieJar()
url_login ='http://127.0.0.1:8000/admin/'
body =
{'csrfmiddlewaretoken':'f85a33be11bd85108a1030fcce96a5ea','username':'root','password':'mypass','this_is_the_login_form':'1'}
opener=urllib2.build_opener(urllib2.HTTPCookieProcessor(cj))
opener.addheaders = [('User-agent','Mozilla/4.0 (compatible; MSIE 7.0;
Windows NT 5.1)')]
urllib2.install_opener(opener)
req=urllib2.Request(url_login,urllib.urlencode(body))
u=urllib2.urlopen(req)
print u.read()
print urllib2.urlopen("http://127.0.0.1:8000/admin/sites/
site/").read()
but the codes don't seem to work,here is some part of the response
---
Looks like your browser isn't configured to
accept cookies. Please enable cookies, reload this page, and try
again.
Username:
Password:
Could anyone give some suggestion?
--
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: How to post data to the admin form by urllib2 ?
Please do not cross-post to django-developers and django-users.
http://groups.google.com/group/django-users/browse_thread/thread/6fb15b60f1e551c0#
This group is for discussion about development *of* Django itself, not
development *using* Django.
On Tue, Jul 27, 2010 at 9:05 PM, jerry wrote:
> Hi:
> I build a website and want to login the admin form by python code. I
> have disabled the CSRF in my project and use urllib2 to post data.
> here are my codes:
>
>
> import urllib
> import urllib2
> import cookielib
>
> cj = cookielib.CookieJar()
> url_login ='http://127.0.0.1:8000/admin/'
> body =
>
> {'csrfmiddlewaretoken':'f85a33be11bd85108a1030fcce96a5ea','username':'root','password':'mypass','this_is_the_login_form':'1'}
> opener=urllib2.build_opener(urllib2.HTTPCookieProcessor(cj))
> opener.addheaders = [('User-agent','Mozilla/4.0 (compatible; MSIE 7.0;
> Windows NT 5.1)')]
> urllib2.install_opener(opener)
> req=urllib2.Request(url_login,urllib.urlencode(body))
> u=urllib2.urlopen(req)
> print u.read()
> print urllib2.urlopen("http://127.0.0.1:8000/admin/sites/
> site/").read()
>
>
>
> but the codes don't seem to work,here is some part of the response
>
> ---
>
> Looks like your browser isn't configured to
> accept cookies. Please enable cookies, reload this page, and try
> again.
>
>
> style='display:none'> value='678f0507075332a87211dff43d6f9ee4' />
>
> Username: name="username" id="id_username" />
>
>
> Password: name="password" id="id_password" />
>
>
>
>
>
>
>
>
> Could anyone give some suggestion?
>
> --
> 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.
>
>
--
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: How to post data to the admin form by urllib2 ?
On Wed, Jul 28, 2010 at 11:05 AM, jerry wrote:
> Hi:
> I build a website and want to login the admin form by python code. I
> have disabled the CSRF in my project and use urllib2 to post data.
> here are my codes:
>
>
> import urllib
> import urllib2
> import cookielib
>
> cj = cookielib.CookieJar()
> url_login ='http://127.0.0.1:8000/admin/'
> body =
>
> {'csrfmiddlewaretoken':'f85a33be11bd85108a1030fcce96a5ea','username':'root','password':'mypass','this_is_the_login_form':'1'}
> opener=urllib2.build_opener(urllib2.HTTPCookieProcessor(cj))
> opener.addheaders = [('User-agent','Mozilla/4.0 (compatible; MSIE 7.0;
> Windows NT 5.1)')]
> urllib2.install_opener(opener)
> req=urllib2.Request(url_login,urllib.urlencode(body))
> u=urllib2.urlopen(req)
> print u.read()
> print urllib2.urlopen("http://127.0.0.1:8000/admin/sites/
> site/").read()
>
>
>
> but the codes don't seem to work,here is some part of the response
>
> ---
>
> Looks like your browser isn't configured to
> accept cookies. Please enable cookies, reload this page, and try
> again.
>
>
> style='display:none'> value='678f0507075332a87211dff43d6f9ee4' />
>
> Username: name="username" id="id_username" />
>
>
> Password: name="password" id="id_password" />
>
>
>
>
>
>
>
>
> Could anyone give some suggestion?
>
> --
> 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.
>
>
Hi Jerry
This mailing list is for development of Django, for help with using Django
you want django-users (http://groups.google.com/group/django-users)
Thanks
--
Rory Hart
http://blog.roryhart.net
--
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.
