Re: Oracle/GIS Testers Needed

[Jani Tiainen]

On Fri, 2009-11-20 at 01:14 -0500, Alex Gaynor wrote:
> Hey all,
> 
> Russ and I have been working on getting the multi-db work ready for
> merge (final stretch here hopefully!), and I just ported the Oracle
> backend to the slightly updated backend arcitecture so it could use
> some testers.  If you've got an Oracle setup and can run some tests
> that would be great.  You can grab the code here:
> 
> http://github.com/alex/django/tree/multiple-db
> 
> Make sure you use the multiple-db branch.  I understand running the
> tests under Oracle can be a bit slow, so perhaps start by just running
> the "queries" tests, if they fail please reply with the complete
> tracebacks and such here, otherwise if you have the time a shot at
> running the full test suite would be great.
> 
> For GIS I'm fairly certain that's broken, however I'm not quite setup
> for running the GIS tests yet, therefore if you're set up for it and
> can run the tests please just reply with your tracebacks here
> (preferably with them on a pastebin like paste.pocoo.org though :))
> and I'll try to sort it out.
> 
> Thanks all,
> Alex
> 

We can try to run and experiment all that since we need multidb support
and we run Oracle with heavy GIS stuff. 

Is there any special requirements that I need to take account before
running tests?

-- 

Jani Tiainen



--

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

Oracle/GIS Testers Needed

[Alex Gaynor]

Hey all,

Russ and I have been working on getting the multi-db work ready for
merge (final stretch here hopefully!), and I just ported the Oracle
backend to the slightly updated backend arcitecture so it could use
some testers.  If you've got an Oracle setup and can run some tests
that would be great.  You can grab the code here:

http://github.com/alex/django/tree/multiple-db

Make sure you use the multiple-db branch.  I understand running the
tests under Oracle can be a bit slow, so perhaps start by just running
the "queries" tests, if they fail please reply with the complete
tracebacks and such here, otherwise if you have the time a shot at
running the full test suite would be great.

For GIS I'm fairly certain that's broken, however I'm not quite setup
for running the GIS tests yet, therefore if you're set up for it and
can run the tests please just reply with your tracebacks here
(preferably with them on a pastebin like paste.pocoo.org though :))
and I'll try to sort it out.

Thanks all,
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-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=.

Re: validation.py backwards incompatibility for fieldsets

[rebus_]

2009/11/19 Russell Keith-Magee :
> On Thu, Nov 19, 2009 at 10:35 PM, rebus_  wrote:
>
> Thanks for the report! You've definitely found a problem, and your
> test case made it easy to narrow it down. Your patch wasn't quite
> right - it resulted in an incorrect error message for a different edge
> case (the unrelated error message that your testcase patch modified),
> but it was enough to get me to the right patch.
>
> I've (hopefully) fixed the problem in r11752.
>
> Thanks again,
> Russ Magee %-)
>

I was thinking of similar patch, but couldn't decided which way to go.
I guessed flatten_fieldsets would be more appropriate as it didn't
introduced yet another loop, but you're right. This is much better way
to handle it since the other testcase still passes as it should.

Thanks for fixing this.

--
Davor Lučić

--

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

Re: validation.py backwards incompatibility for fieldsets

[Russell Keith-Magee]

On Thu, Nov 19, 2009 at 10:35 PM, rebus_  wrote:
> Hi,
>
> This is my first bug report so please don't shoot me right away.
>
> In revision 11744 [1] code was added in
> django/contrib/admin/validation.py which is supposed to improve the
> error message for M2M fields. It seems to me that this change has
> broken ability to display multiple fields on the same line in
> administration.

Thanks for the report! You've definitely found a problem, and your
test case made it easy to narrow it down. Your patch wasn't quite
right - it resulted in an incorrect error message for a different edge
case (the unrelated error message that your testcase patch modified),
but it was enough to get me to the right patch.

I've (hopefully) fixed the problem in r11752.

Thanks again,
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=.

validation.py backwards incompatibility for fieldsets

[rebus_]

Hi,

This is my first bug report so please don't shoot me right away.

In revision 11744 [1] code was added in
django/contrib/admin/validation.py which is supposed to improve the
error message for M2M fields. It seems to me that this change has
broken ability to display multiple fields on the same line in
administration.


For example lets take this Model and AdminModel:

class InlineFieldsets(models.Model):
a = models.CharField(max_length=100)
b = models.CharField(max_length=100)
c = models.CharField(max_length=100)

class InlineFieldsetsAdmin(admin.ModelAdmin):
fieldsets = (
('Header 1', {'fields': ('a',('b', 'c'))}),
)

This will now fail horribly. Once the loop in
django/contrib/admin/validation...@222  gets to the ('b', 'c') fields
subset it will pass ('b', 'c') as `field` argument to
check_formfield() function which will raise

ImproperlyConfigured: 'InlineFieldsetsAdmin.fieldsets[0][1]['fields']'
refers to field '('b', 'c')' that is missing from the form.


Instead, i think fieldset should first be flattened then go through
the loop, call check_formfield() and check for M2M fields etc. like
so:

flattened_fieldsets = flatten_fieldsets(cls.fieldsets)
for field in flattened_fieldsets:
   check_formfield(cls, model, opts, "fieldsets[%d][1]['fields']" % idx, field)
   

instead the way it does it now:
for field in fieldset[1]['fields']:
   check_formfield(cls, model, opts, "fieldsets[%d][1]['fields']" % idx, field)
   
flattened_fieldsets = flatten_fieldsets(cls.fieldsets)

Patch is attached, i can open up a new ticket if you want.
I have ran runtests.py with this patch applied and everything passes.
But then again i am not python nor django guru so i can't be sure
everything is ok.
I have also added regression tests for this case. Hope this patch can help.

[1] http://code.djangoproject.com/changeset/11744

--
Davor Lučić

--

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


Index: django/contrib/admin/validation.py
===
--- django/contrib/admin/validation.py  (revision 11751)
+++ django/contrib/admin/validation.py  (working copy)
@@ -219,7 +219,8 @@
 raise ImproperlyConfigured("'fields' key is required in "
 "%s.fieldsets[%d][1] field options dict."
 % (cls.__name__, idx))
-for field in fieldset[1]['fields']:
+flattened_fieldsets = flatten_fieldsets(cls.fieldsets)
+for field in flattened_fieldsets:
 check_formfield(cls, model, opts, "fieldsets[%d][1]['fields']" 
% idx, field)
 try:
 f = opts.get_field(field)
@@ -232,7 +233,6 @@
 # If we can't find a field on the model that matches,
 # it could be an extra field on the form.
 pass
-flattened_fieldsets = flatten_fieldsets(cls.fieldsets)
 if len(flattened_fieldsets) > len(set(flattened_fieldsets)):
 raise ImproperlyConfigured('There are duplicate field(s) in 
%s.fieldsets' % cls.__name__)
 
Index: tests/regressiontests/admin_validation/models.py
===
--- tests/regressiontests/admin_validation/models.py(revision 11751)
+++ tests/regressiontests/admin_validation/models.py(working copy)
@@ -40,12 +40,25 @@
 book = models.ForeignKey(Book)
 
 
+class InlineFieldsets(models.Model):
+a = models.CharField(max_length=1)
+b = models.CharField(max_length=1)
+c = models.CharField(max_length=1)
+
+
 __test__ = {'API_TESTS':"""
 
 >>> from django import forms
 >>> from django.contrib import admin
 >>> from django.contrib.admin.validation import validate, validate_inline
 
+>>> class InlineFieldsetsAdmin(admin.ModelAdmin):
+...fieldsets = (
+...('Header 1', {'fields': ('a',('b', 'c'))}),
+...)
+
+>>> validate(InlineFieldsetsAdmin, InlineFieldsets)
+
 # Regression test for #8027: custom ModelForms with fields/fieldsets
 
 >>> class SongForm(forms.ModelForm):
@@ -129,7 +142,7 @@
 >>> validate(FieldsetBookAdmin, Book)
 Traceback (most recent call last):
...
-ImproperlyConfigured: 'FieldsetBookAdmin.fieldsets[1][1]['fields']' can't 
include the ManyToManyField field 'authors' because 'authors' manually 
specifies a 'through' model.
+ImproperlyConfigured: 'FieldsetBookAdmin.fieldsets[0][1]['fields']' can't 
include the ManyToManyField field 'authors' because 'authors' manually 
specifies a 'through' model.
 
 # Regression test for #12209 -- If the explicitly provided through model
 # is specified as a string, the admin should still 

Re: Scaffolding

[gareth rushgrove]

2009/11/19 Russell Keith-Magee :
> On Thu, Nov 19, 2009 at 6:47 PM, Thierry  
> wrote:
>> Ok scaffolding has seen a lot of ups and downs in the dev community.
>>
>> Type 2
>> Intelligent code snippets (generation) such as create_app
>>
>> Django needs more of the later.
>> If i have a model, i would like to be able to generate:
>> - 2 views (list, edit-detail-remove)
>> - 2 templates
>> - a modelform
>> - the neccesary url config
>>
>> So I can start working from there, instead of starting from scratch.
>> Symfony had this nicely worked out.
>> Is there any django design convention which stops us from having a
>> management command for this type of Scaffolding?
>
>
> However, if you're enthused about having more scaffolding-style tools,
> then you can start this as a standalone project - after all, you are
> able to define your own management commands if you want. If it turns
> out that your management commands are particularly useful and develop
> a strong following as an external project, then we can see about
> merging them into the core.
>

I've been using paster for this and it works really well. I've started
compiling these into a project on GitHub based on a few conventions
myself and a few others use:

http://github.com/garethr/django-project-templates

At the moment I only have one overall template but am just finishing
off templates for production configs on different environments
(apache, mod_wsgi, spawning) and but I'd be happy for others to get
involved. If nothing else feel free to steal the paster template code.

Reading this makes me think wrapping this in a management command
would make it easier for Django people to get started.

Ta

G

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



-- 
Gareth Rushgrove

Web Geek
Member WaSP Education Task Force

morethanseven.net
garethrushgrove.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-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=.

Re: Scaffolding

[Russell Keith-Magee]

On Thu, Nov 19, 2009 at 6:47 PM, Thierry  wrote:
> Ok scaffolding has seen a lot of ups and downs in the dev community.
>
> Type 1
> "lets generate code, because that way our programming language sucks
> less" approach some PHP frameworks take.
>
> Type 2
> Intelligent code snippets (generation) such as create_app
>
> Django needs more of the later.
> If i have a model, i would like to be able to generate:
> - 2 views (list, edit-detail-remove)
> - 2 templates
> - a modelform
> - the neccesary url config
>
> So I can start working from there, instead of starting from scratch.
> Symfony had this nicely worked out.
> Is there any django design convention which stops us from having a
> management command for this type of Scaffolding?

Well, there isn't a formal design convention prohibiting such an
approach - we just haven't seen the need. Generic views cover most of
the simple cases without the need for any sort of scaffolding, and if
you have a complex case, writing the code from scratch just isn't that
hard. Personally, I don't even use startapp that much - it's just as
easy to create a directory and put files in it.

However, if you're enthused about having more scaffolding-style tools,
then you can start this as a standalone project - after all, you are
able to define your own management commands if you want. If it turns
out that your management commands are particularly useful and develop
a strong following as an external project, then we can see about
merging them into the core.

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

Re: CACHE_BACKEND = 'locmem:///' <-> 'locmem://'

[Russell Keith-Magee]

On Thu, Nov 19, 2009 at 6:52 PM, jedie  wrote:
> What is the right "spelling": 'locmem:///' or 'locmem://' ???
>
> In the docu is three "/" [1]
> but in global_settings.py is two "/" [2]
>
> [1] http://docs.djangoproject.com/en/dev/topics/cache/#local-memory-caching
> [2] 
> http://code.djangoproject.com/browser/django/trunk/django/conf/global_settings.py?rev=11709#L329

In practice, it actually doesn't matter. Both are parsed the same by
the cache backend.

However, for consistency, we should pick one and stick to it. I've
updated the docs in r11750 and r11751. Thanks for the report.

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

cache middleware on multi sites...

[jedie]

There exist some "intersection" on multi site installation, if i use
django.middleware.cache.UpdateCacheMiddleware and
django.middleware.cache.FetchFromCacheMiddleware

Problem:
The cache key would be only generated based on the url without the
domain name. So if the page /foobar/ exist on site A and site B but
with different content, they would be only caches one time.

Solutions:
1. The user can insert this into his settings:
CACHE_MIDDLEWARE_KEY_PREFIX = "FooBar %s" % SITE_ID

2. Django should insert the SITE_ID into cache key. e.g. in
django.utils.cache.get_cache_key()

3. Django should use the complete path to build the cache key. e.g.:
use request.build_absolute_uri() in
django.utils.cache._generate_cache_header_key() instead of iri_to_uri
(request.path)

Mfg.

Jens Diemer

--

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

Scaffolding

[Thierry]

Ok scaffolding has seen a lot of ups and downs in the dev community.

Type 1
"lets generate code, because that way our programming language sucks
less" approach some PHP frameworks take.

Type 2
Intelligent code snippets (generation) such as create_app

Django needs more of the later.
If i have a model, i would like to be able to generate:
- 2 views (list, edit-detail-remove)
- 2 templates
- a modelform
- the neccesary url config

So I can start working from there, instead of starting from scratch.
Symfony had this nicely worked out.
Is there any django design convention which stops us from having a
management command for this type of Scaffolding?

--

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