Just curious, why is admin.site.register([Model], [ModelAdmin]) not done within ModelAdmin?

[Joshua Russo]

I've wondered this for a while, but is there a reason why the call to 
admin.site.register(([Model], [ModelAdmin]) is not done within the init of 
ModelAdmin?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/OxXmz1Obc0oJ.
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: Just curious, why is admin.site.register([Model], [ModelAdmin]) not done within ModelAdmin?

[Joshua Russo]

gotcha, thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/z1jxGo07QQIJ.
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.

Is there any particular reason why it's assumed you won't be performing a Max on a CharField?

[Joshua Russo]

I posted this in the users group but didn't get any response, so I'm 
bringing it here. 

Is there any particular reason why it's assumed you won't be performing a 
Max on a CharField? 

I tried to create the following QuerySet I get an error out of 
convert_values() of BaseDatabaseOperations in 
django/db/backends/__init__.py:

Document.objects.filter(documentType=1, 
event__eventType=3).annotate(event_date=Max('event__start_date'), 
subcommittee=Max('event__subcommittee__name')).order_by('subcommittee', 
'event_date')

The reason why I performed a Max on the subcommittee name is that the 
relation between Document and Event is actually a many to many, but I 
enforce this particular documentType to only once per Event. 

The fix is easy. Add any character based field types to the last elif in 
convert_values(). I plan on submitting a patch unless there's a compelling 
reason not to

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/mGzHtBFTeOEJ.
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.

New to open source dev

[Joshua Russo]

I have been tinkering with some custom objects for db fields, form
fields, and widgets and have seen one or two things that might be nice
enhancements to the base objects. How exactly does the process of
contributing work?

I was actually coming here to gauge peoples opinion to my suggestions
but I'm not even sure if this is the proper place to ask if a mod is a
good idea or not.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Debugging unit test?

[Joshua Russo]

What do you use to debug the unit tests? I've been using Netbeans 6.5
with the Python plugin but it's a bit buggy still and the unit tests
seem to have real issues with the debugger at the moment.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

documentation needs a small update in regards to custom sql

[Joshua Russo]

It might be helpful to link to or some how reference the reset
subcommand in the sqlrest subcommands.

sqlrest doesn't reference sqlall or reset currently. Both would be
helpful seeing as sqlall is the main concept it follows (besides the
deletions) and reset is how to actually execute what you see.

I just had to traverse the code to figure out how the custom sql
actually gets executed.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Change list default sort modification proposal

[Joshua Russo]

I just wanted to toss this out there before creating the ticket. I've
tweaked the change list sort handling so that by default it uses the
full list of sort columns defined in the model. It sets all of the
headers as unselected and then behaves as it currently does if someone
selects a header column to sort by. I've also modified the template to
add a Reset sort (or conditionally Reset sort and filter) button to
bring everything back to the original state.

Does this sound like something that is desired?
--~--~-~--~~~---~--~~
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: Change list default sort modification proposal

[Joshua Russo]

On Tue, Aug 11, 2009 at 7:46 PM, Rock  wrote:

>
> Yes. I have a project that could use this immediately. Looking forward
> to seeing the ticket and a patch I can try out.


Ok, let me know what you think.
http://code.djangoproject.com/ticket/11695

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Form.Widgets use of Super (of lack there of)?

[Joshua Russo]

Why is it that Super is only used sometimes in the __init__ methods of the
existing widgets? Is this by design? I thought that if you used Super
anywhere you had to use it everywhere, otherwise the one place you do use it
wouldn't behave the way you anticipate. That is, if anyone ever uses
multiple inheritance and Super is used sporadically the chain will break at
the first non-existing Super call.
Here is where I'm seeing it missing:
Widget (this is really the biggest problem it seems)
Textarea

Should I create a ticket with the Super calls added to these two?

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Feature proposal: admin.ModelAdmin modified hook

[Joshua Russo]

I've implemented a simple hook called model_modified() that can be extended
in the user's ModelAdmin class. It's called after a New, Update, or Delete
action is taken. I've used it in my application to clear related session
information that I use to cache heavy query results.
Does this sound like an appropriate extension?

--~--~-~--~~~---~--~~
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: Inline formsets

[Joshua Russo]

On Sat, Aug 15, 2009 at 8:45 PM, mrts  wrote:

>
> At HTML level, a form is a set of fields that gets submitted when
> a the form submit button is pressed.
>
> However, this is not the case with model forms and inline formsets
> (e.g. an admin page with inlines) -- inline formsets are
> disparate from the model form.
>
> This creates at least two problems:
> 1) it's impossible to display inline formsets in between ordinary
> form fields (although they may logically belong to a particular
> fieldset and not to the end of the form),
> 2) it's impossible to create nested (recursive) inlines.
>
> There's more to it though. Inline formsets usually represent
> composition, i.e. the inline objects are inseparable from the
> main entity. The relation is stronger than a ForeignKey (from the
> main entity to another entity), yet the latter is displayed as a
> field of the form and can be easily manipulated -- but inlines
> are not.
>
> What I propose may at first sound odd: adding a *formset field*
> to forms (keen readers notice the Composite pattern in work
> here):
>
> FormsetField(form=CustomFormClass, << other options inspired by
> admin inlines and formset factories >>)
>
> It would overcome both of the problems mentioned above and, being
> object-based, would be generally more flexible than the factories
> currently in use. Nested formsets can be trivially created:
>
> class Foo(forms.Form):
>   foo = forms.FormsetField(...)
>
> class Bar(forms.Form):
>   foos = forms.FormsetField(form=Foo, ...) # <-- nested formset
>
> Rendering
> -
>
> In an ideal world, the would-be formset field would support all
> the niceness present or coming to Django admin: add/delete
> instances on the fly, collapsing and reordering. That means
> coupling JS to forms layer, which seems to be frowned upon.
> Leaving either abstractions/hooks in place to support that
> functionality and/or document how to bind the JS would
> probably suffice though.
>
> Implications for contrib.admin
> --
>
> FormsetField would be the recommended way for displaying and
> manipulating inlines.
>
> In yet another ideal world, assembling your own contrib.admin
> would be trivial. All the functionality might be nicely packaged
> to cohesive components (generic views, Alex's django-filter etc)
> -- contrib.admin would be just a thin wrapper that binds all
> reusable bits into a harmonious whole.
>
> A rich FormsetField would contribute to that, making working with
> formsets less onerous.
> >

I think this sounds like a great idea. Do you have any code in place yet?
This was probably the first thing I noticed I would like changed when
getting into Django development.

--~--~-~--~~~---~--~~
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: Feature proposal: admin.ModelAdmin modified hook

[Joshua Russo]

Oh that's right, reason I put this in ModelAdmin is because I'm clearing
session variables and so I need the request object. (So signals won't work.
I don't believe.) When dealing with the request object there isn't a real
clean way to centralize management like this. By adding the model_modified
hook I was at least able to deal with all CRUD cases at once per model.
On Mon, Aug 17, 2009 at 1:10 PM, Joshua Russo wrote:

> The problem with simply extending the save method is that it doesn't cover
> deletes.
> I will try hooking into both post_save and post_delete signals though I was
> looking for a more unified approach, to avoid repetition.
>
>
> On Mon, Aug 17, 2009 at 12:11 PM, Marc Remolt 
> wrote:
>
>>
>> May I ask why you don't simply extend the models save method or use a
>> post save signal
>> (
>> http://docs.djangoproject.com/en/dev/ref/signals/#django.db.models.signals.post_save
>> )?
>> Do you really want the cleanups only if the object is saved via the
>> admin or whenever it is saved - for example in your own views?
>>
>> If you really want the first variant, there already is such a hook -
>> kind of:
>> In ModelAdmin, you can override save_model
>> (
>> http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L553
>> )
>> to do any pre or post save actions.
>>
>> So I guess from your use case, this hook won't be necessary.
>>
>> Cheers
>> Marc
>>
>>
>> Joshua Russo schrieb:
>> > I've implemented a simple hook called model_modified() that can be
>> > extended in the user's ModelAdmin class. It's called after a New,
>> > Update, or Delete action is taken. I've used it in my application to
>> > clear related session information that I use to cache heavy query
>> > results.
>> >
>> > Does this sound like an appropriate extension?
>> >
>> > >
>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: Feature proposal: admin.ModelAdmin modified hook

[Joshua Russo]

The problem with simply extending the save method is that it doesn't cover
deletes.
I will try hooking into both post_save and post_delete signals though I was
looking for a more unified approach, to avoid repetition.


On Mon, Aug 17, 2009 at 12:11 PM, Marc Remolt wrote:

>
> May I ask why you don't simply extend the models save method or use a
> post save signal
> (
> http://docs.djangoproject.com/en/dev/ref/signals/#django.db.models.signals.post_save
> )?
> Do you really want the cleanups only if the object is saved via the
> admin or whenever it is saved - for example in your own views?
>
> If you really want the first variant, there already is such a hook -
> kind of:
> In ModelAdmin, you can override save_model
> (
> http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L553
> )
> to do any pre or post save actions.
>
> So I guess from your use case, this hook won't be necessary.
>
> Cheers
> Marc
>
>
> Joshua Russo schrieb:
> > I've implemented a simple hook called model_modified() that can be
> > extended in the user's ModelAdmin class. It's called after a New,
> > Update, or Delete action is taken. I've used it in my application to
> > clear related session information that I use to cache heavy query
> > results.
> >
> > Does this sound like an appropriate extension?
> >
> > >
>
>
> >
>

--~--~-~--~~~---~--~~
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: Feature proposal: admin.ModelAdmin modified hook

[Joshua Russo]

On Mon, Aug 17, 2009 at 1:44 PM, Jacob Kaplan-Moss wrote:

>
> On Mon, Aug 17, 2009 at 9:10 AM, Joshua Russo
> wrote:
> > I will try hooking into both post_save and post_delete signals though I
> was
> > looking for a more unified approach, to avoid repetition.
>
> You may already know this, but you can hook the same method up to
> multiple signals::
>
>def handle_save_or_delete(sender, **kwargs):
>...
>
>post_save.connect(handle_save_or_delete)
>post_delete.connect(handle_save_or_delete)
>
> That's your save-or-delete signal, right there.
>

Thanks for the tip. I actually haven't played around with signals too much,
but I figured that was possible.

As for my hook, do you think it's valuable, or should I just keep it to
myself? It's all written I just need to submit the 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-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
-~--~~~~--~~--~--~---

Feature proposal: Test client form value extraction

[Joshua Russo]

I've just put together an enhancement of the test Client used in unit
testing. I added the parsing of the content to extract the form fields with
their initial values as a dictionary, so you can just change a few values
and throw it back at the server.
http://dpaste.com/hold/85281/

I had to do a small monkey patch to get it to work because direct override
of the __ call __ method interfered with the transaction management for some
reason.

Let me know what you think. Should I submit it as a ticket?

--~--~-~--~~~---~--~~
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: Feature proposal: Test client form value extraction

[Joshua Russo]

On Aug 25, 6:09 pm, Joshua Russo  wrote:
> I've just put together an enhancement of the test Client used in unit
> testing. I added the parsing of the content to extract the form fields with
> their initial values as a dictionary, so you can just change a few values
> and throw it back at the server.http://dpaste.com/hold/85281/
>
> I had to do a small monkey patch to get it to work because direct override
> of the __ call __ method interfered with the transaction management for some
> reason.
>
> Let me know what you think. Should I submit it as a ticket?

Here is a basic usage example:

def test_htmlParse(self):

response = self.client.get('/test/')
self.failUnlessEqual(response.status_code, 200, 'Failed to
retrieve the form test page. (1)')

curVals = response.form_values['frmTest']

response = self.client.post('/test/', curVals)
self.failUnlessEqual(response.status_code, 200, 'Failed to
retrieve the form test page. (2)')
--~--~-~--~~~---~--~~
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: Feature proposal: Test client form value extraction

[Joshua Russo]

I figured someone had done this at some time.

What's the general consensus on when some thing like this should
be considered to be added to the project and when it should just stay as an
outside utility?


On Wed, Aug 26, 2009 at 7:11 AM, Thomas Guettler  wrote:

>
> Hi,
>
> some time ago I wrote a snippet which does this:
>
> http://www.djangosnippets.org/snippets/467/
>
> {{{
> If you want to test a post request to a form, you need to give all input
> fields, even if you just want to test if one
> value gets changed.
>
> This snippets parses the HTML of a view and gives you a dictionary that you
> can give to django.test.Client.
>
> Needs ClientForm from: http://wwwsearch.sourceforge.net/ClientForm/
> }}}
>
>
> Joshua Russo schrieb:
> > I've just put together an enhancement of the test Client used in unit
> > testing. I added the parsing of the content to extract the form fields
> with
> > their initial values as a dictionary, so you can just change a few values
> > and throw it back at the server.
> > http://dpaste.com/hold/85281/
> >
> > I had to do a small monkey patch to get it to work because direct
> override
> > of the __ call __ method interfered with the transaction management for
> some
> > reason.
> >
> > Let me know what you think. Should I submit it as a ticket?
>
> --
> Thomas Guettler, http://www.thomas-guettler.de/
> E-Mail: guettli (*) thomas-guettler + de
>
> >
>

--~--~-~--~~~---~--~~
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: Feature proposal: Test client form value extraction

[Joshua Russo]

On Wed, Aug 26, 2009 at 12:52 PM, Russell Keith-Magee <
freakboy3...@gmail.com> wrote:

>
> On Wed, Aug 26, 2009 at 4:41 PM, Joshua Russo
> wrote:
> > I figured someone had done this at some time.
> > What's the general consensus on when some thing like this should
> > be considered to be added to the project and when it should just stay as
> an
> > outside utility?
>
> It's certainly worth putting up as a ticket. I can agree with the
> original use case - that is, using the client.get() to construct the
> prototype data dictionary that will be passed to client.post(). You
> only have to look at the work that is done in the admin tests to see
> the value in this proposal.
>
> However, I have some reservations about the patch.
>
> Most notably, I'm not sure I see how your patch answers the original
> use case. The form data structure that is returned by the parser
> appears to contain a top-level dictionary containing the form
> instances. The form structure itself is irrelevant to reposting.
>
> However, thats not to say that keeping the form data is irrelevant.
> For example, consider the case where a page has multiple forms, or
> multiple submit buttons on a single form. If we're going to introduce
> a utility like this, then it should be able to behave at least
> partially like a browser - that is, I should be able to get the post
> data that is needed to respond to a specific button press:
>
> response = self.client.get('/path/to/page')
> # Get a copy of a data dictionary that contains the form data
> # that would be submitted if I pressed the submit button labeled 'button 3'
> data = response.form_data('button 3')
> data['some-field'] = 'new value'
> response = self.client.post('/path/to/page', data)
>
> We also need to be careful of feature creep - this sort of testing is
> exactly what Twill does, and we don't want to duplicate the efforts of
> that project (or any other automated Python client test framework for
> that matter).
>

That seems reasonable. I'll work on it and let you know when I have an
official patch ready.

--~--~-~--~~~---~--~~
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: Feature proposal: Test client form value extraction

[Joshua Russo]

On Wed, Aug 26, 2009 at 1:34 PM, Joshua Russo wrote:

> On Wed, Aug 26, 2009 at 12:52 PM, Russell Keith-Magee <
> freakboy3...@gmail.com> wrote:
>
>>
>> On Wed, Aug 26, 2009 at 4:41 PM, Joshua Russo
>> wrote:
>> > I figured someone had done this at some time.
>> > What's the general consensus on when some thing like this should
>> > be considered to be added to the project and when it should just stay as
>> an
>> > outside utility?
>>
>> It's certainly worth putting up as a ticket. I can agree with the
>> original use case - that is, using the client.get() to construct the
>> prototype data dictionary that will be passed to client.post(). You
>> only have to look at the work that is done in the admin tests to see
>> the value in this proposal.
>>
>> However, I have some reservations about the patch.
>>
>> Most notably, I'm not sure I see how your patch answers the original
>> use case. The form data structure that is returned by the parser
>> appears to contain a top-level dictionary containing the form
>> instances. The form structure itself is irrelevant to reposting.
>>
>> However, thats not to say that keeping the form data is irrelevant.
>> For example, consider the case where a page has multiple forms, or
>> multiple submit buttons on a single form. If we're going to introduce
>> a utility like this, then it should be able to behave at least
>> partially like a browser - that is, I should be able to get the post
>> data that is needed to respond to a specific button press:
>>
>> response = self.client.get('/path/to/page')
>> # Get a copy of a data dictionary that contains the form data
>> # that would be submitted if I pressed the submit button labeled 'button
>> 3'
>> data = response.form_data('button 3')
>> data['some-field'] = 'new value'
>> response = self.client.post('/path/to/page', data)
>>
>> We also need to be careful of feature creep - this sort of testing is
>> exactly what Twill does, and we don't want to duplicate the efforts of
>> that project (or any other automated Python client test framework for
>> that matter).
>>
>
> That seems reasonable. I'll work on it and let you know when I have an
> official patch ready.
>

Let me know how this looks.

http://dpaste.com/hold/86057/

The only question I have is when I encounter a Form that doesn't have a name
or an id, should the index be a real number or should I convert it into a
string for consistency?

--~--~-~--~~~---~--~~
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: Feature proposal: Test client form value extraction

[Joshua Russo]

On Thu, Aug 27, 2009 at 11:54 AM, Joshua Russo wrote:

> On Wed, Aug 26, 2009 at 1:34 PM, Joshua Russo wrote:
>
>> On Wed, Aug 26, 2009 at 12:52 PM, Russell Keith-Magee <
>> freakboy3...@gmail.com> wrote:
>>
>>>
>>> On Wed, Aug 26, 2009 at 4:41 PM, Joshua Russo
>>> wrote:
>>> > I figured someone had done this at some time.
>>> > What's the general consensus on when some thing like this should
>>> > be considered to be added to the project and when it should just stay
>>> as an
>>> > outside utility?
>>>
>>> It's certainly worth putting up as a ticket. I can agree with the
>>> original use case - that is, using the client.get() to construct the
>>> prototype data dictionary that will be passed to client.post(). You
>>> only have to look at the work that is done in the admin tests to see
>>> the value in this proposal.
>>>
>>> However, I have some reservations about the patch.
>>>
>>> Most notably, I'm not sure I see how your patch answers the original
>>> use case. The form data structure that is returned by the parser
>>> appears to contain a top-level dictionary containing the form
>>> instances. The form structure itself is irrelevant to reposting.
>>>
>>> However, thats not to say that keeping the form data is irrelevant.
>>> For example, consider the case where a page has multiple forms, or
>>> multiple submit buttons on a single form. If we're going to introduce
>>> a utility like this, then it should be able to behave at least
>>> partially like a browser - that is, I should be able to get the post
>>> data that is needed to respond to a specific button press:
>>>
>>> response = self.client.get('/path/to/page')
>>> # Get a copy of a data dictionary that contains the form data
>>> # that would be submitted if I pressed the submit button labeled 'button
>>> 3'
>>> data = response.form_data('button 3')
>>> data['some-field'] = 'new value'
>>> response = self.client.post('/path/to/page', data)
>>>
>>> We also need to be careful of feature creep - this sort of testing is
>>> exactly what Twill does, and we don't want to duplicate the efforts of
>>> that project (or any other automated Python client test framework for
>>> that matter).
>>>
>>
>> That seems reasonable. I'll work on it and let you know when I have an
>> official patch ready.
>>
>
> Let me know how this looks.
>
> http://dpaste.com/hold/86057/
>
> The only question I have is when I encounter a Form that doesn't have a
> name or an id, should the index be a real number or should I convert it into
> a string for consistency?
>

Ok, so I found that the way I was 'casting' the response object didn't work.
Is there no way to cast an instance of a base class to a child class in
Python?

What I did was to create a class method on my child class that takes the
current response instance and creates a copy of it using my new response
object.

 http://dpaste.com/hold/86193/

Does this look appropriate, or is there a better way to do this?

--~--~-~--~~~---~--~~
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: Feature proposal: Test client form value extraction

[Joshua Russo]

On Thu, Aug 27, 2009 at 6:22 PM, Forest Bond wrote:

> Hi,
>
> On Thu, Aug 27, 2009 at 03:28:03PM -0100, Joshua Russo wrote:
> > On Thu, Aug 27, 2009 at 11:54 AM, Joshua Russo 
> wrote:
> > Ok, so I found that the way I was 'casting' the response object didn't
> work. Is
> > there no way to cast an instance of a base class to a child class in
> Python?
> >
> > What I did was to create a class method on my child class that takes the
> > current response instance and creates a copy of it using my new response
> > object.
> >
> >  http://dpaste.com/hold/86193/
> >
> > Does this look appropriate, or is there a better way to do this?
>
> This should work:
>
>  response.__class__ = TestHttpResponse
>

Nope, it resets the status_code. That's what I tried at first.

--~--~-~--~~~---~--~~
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: Feature proposal: Test client form value extraction

[Joshua Russo]

On Fri, Aug 28, 2009 at 4:11 PM, Joshua Russo wrote:

> On Thu, Aug 27, 2009 at 10:39 PM, Forest Bond 
> wrote:
>
>> Hi,
>>
>> On Thu, Aug 27, 2009 at 07:42:24PM -0100, Joshua Russo wrote:
>> > On Thu, Aug 27, 2009 at 6:22 PM, Forest Bond <
>> for...@alittletooquiet.net>
>> > wrote:
>> >
>> >     Hi,
>> >
>> > On Thu, Aug 27, 2009 at 03:28:03PM -0100, Joshua Russo wrote:
>> > > On Thu, Aug 27, 2009 at 11:54 AM, Joshua Russo <
>> josh.r.ru...@gmail.com>
>> > wrote:
>> > > Ok, so I found that the way I was 'casting' the response object
>> didn't
>> > work. Is
>> > > there no way to cast an instance of a base class to a child class
>> in
>> > Python?
>> > >
>> > > What I did was to create a class method on my child class that
>> takes the
>> > > current response instance and creates a copy of it using my new
>> response
>> > > object.
>> > >
>> > >  http://dpaste.com/hold/86193/
>> > >
>> > > Does this look appropriate, or is there a better way to do this?
>> >
>> > This should work:
>> >
>> >  response.__class__ = TestHttpResponse
>> >
>> >
>> > Nope, it resets the status_code. That's what I tried at first.
>>
>> Okay, you'd have to copy the class attributes, too.  Or, you could just
>> define a
>> sub-class on-the-fly:
>>
>>  class _TestHttpResponse(TestHttpResponse, response.__class__):
>>  pass
>>
>>  response.__class__ = _TestHttpResponse
>>
>> I haven't tested this.
>
>
> That might just work. I would need to to change the base class of
> TestHttpResponse to Object, but then my class wouldn't (shouldn't) override
> the status_code in the response class. Good idea. Though I may have to wait
> until Monday to test it out.
>
> Thanks
>

Yup that works! Thanks!

--~--~-~--~~~---~--~~
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: Feature proposal: Test client form value extraction

[Joshua Russo]

On Thu, Aug 27, 2009 at 10:39 PM, Forest Bond wrote:

> Hi,
>
> On Thu, Aug 27, 2009 at 07:42:24PM -0100, Joshua Russo wrote:
> > On Thu, Aug 27, 2009 at 6:22 PM, Forest Bond  >
> > wrote:
> >
> > Hi,
> >
> > On Thu, Aug 27, 2009 at 03:28:03PM -0100, Joshua Russo wrote:
> > > On Thu, Aug 27, 2009 at 11:54 AM, Joshua Russo <
> josh.r.ru...@gmail.com>
> > wrote:
> > > Ok, so I found that the way I was 'casting' the response object
> didn't
> > work. Is
> > > there no way to cast an instance of a base class to a child class
> in
> > Python?
> > >
> > > What I did was to create a class method on my child class that
> takes the
> > > current response instance and creates a copy of it using my new
> response
> > > object.
> > >
> > >  http://dpaste.com/hold/86193/
> > >
> > > Does this look appropriate, or is there a better way to do this?
> >
> > This should work:
> >
> >  response.__class__ = TestHttpResponse
> >
> >
> > Nope, it resets the status_code. That's what I tried at first.
>
> Okay, you'd have to copy the class attributes, too.  Or, you could just
> define a
> sub-class on-the-fly:
>
>  class _TestHttpResponse(TestHttpResponse, response.__class__):
>  pass
>
>  response.__class__ = _TestHttpResponse
>
> I haven't tested this.


That might just work. I would need to to change the base class of
TestHttpResponse to Object, but then my class wouldn't (shouldn't) override
the status_code in the response class. Good idea. Though I may have to wait
until Monday to test it out.

Thanks

--~--~-~--~~~---~--~~
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: Feature proposal: Test client form value extraction

[Joshua Russo]

On Fri, Aug 28, 2009 at 4:37 PM, Joshua Russo wrote:

> On Fri, Aug 28, 2009 at 4:11 PM, Joshua Russo wrote:
>
>> On Thu, Aug 27, 2009 at 10:39 PM, Forest Bond > > wrote:
>>
>>> Hi,
>>>
>>> On Thu, Aug 27, 2009 at 07:42:24PM -0100, Joshua Russo wrote:
>>> > On Thu, Aug 27, 2009 at 6:22 PM, Forest Bond <
>>> for...@alittletooquiet.net>
>>> > wrote:
>>> >
>>> > Hi,
>>> >
>>> > On Thu, Aug 27, 2009 at 03:28:03PM -0100, Joshua Russo wrote:
>>> > > On Thu, Aug 27, 2009 at 11:54 AM, Joshua Russo <
>>> josh.r.ru...@gmail.com>
>>> > wrote:
>>> > > Ok, so I found that the way I was 'casting' the response object
>>> didn't
>>> > work. Is
>>> > > there no way to cast an instance of a base class to a child class
>>> in
>>> > Python?
>>> > >
>>> > > What I did was to create a class method on my child class that
>>> takes the
>>> > > current response instance and creates a copy of it using my new
>>> response
>>> > > object.
>>> > >
>>> > >  http://dpaste.com/hold/86193/
>>> > >
>>> > > Does this look appropriate, or is there a better way to do this?
>>> >
>>> > This should work:
>>> >
>>> >  response.__class__ = TestHttpResponse
>>> >
>>> >
>>> > Nope, it resets the status_code. That's what I tried at first.
>>>
>>> Okay, you'd have to copy the class attributes, too.  Or, you could just
>>> define a
>>> sub-class on-the-fly:
>>>
>>>  class _TestHttpResponse(TestHttpResponse, response.__class__):
>>>  pass
>>>
>>>  response.__class__ = _TestHttpResponse
>>>
>>> I haven't tested this.
>>
>>
>> That might just work. I would need to to change the base class of
>> TestHttpResponse to Object, but then my class wouldn't (shouldn't) override
>> the status_code in the response class. Good idea. Though I may have to wait
>> until Monday to test it out.
>>
>> Thanks
>>
>
> Yup that works! Thanks!
>

Building off your suggestion Forest I've actually built a function that is
similar to a factory function.

def castHttpResponse(curClass):
class TestHttpResponse(curClass):

def form_data(self, search_name):
"""
Returns the entire set of form values associated with form of
the given field or form name
"""
if getattr(self, "_form_data", None) is None:
self._form_data = self._get_form_data()
if self._form_data.has_key(search_name):
return self._form_data[search_name]
for form_name, data in self._form_data.items():
if data.has_key(search_name):
return data
raise FieldNotFound("A field or form with the name %s was not
found." % search_name)

def _get_form_data(self):
curParser = FormHTMLParser()
curParser.feed(self.content)
curParser.close()
return curParser.forms

return TestHttpResponse

And then I can just call the function like so:
response.__class__ = castHttpResponse(response.__class__)

I think this is cleaner as it avoids the multiple inheritance.

--~--~-~--~~~---~--~~
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: Open Source Sample

[Joshua Russo]

On Thu, Sep 3, 2009 at 10:03 PM, My Idea  wrote:

> Hello there!
>
> I'm looking for any open source project that uses django 1.x as platform
> for study proposal. I've already in touch with djangobook.com and other
> stuffs  but I'm still missing something more close to real world.
>
> Is there any pet shop app or something like that?
>
> Thank you very much!


This list is only for the development of Django itself. Please direct
questions like this to the django-users list.

--~--~-~--~~~---~--~~
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: proposal: decouple admin index page from INSTALLED_APPS

[Joshua Russo]

On Fri, Sep 4, 2009 at 8:00 AM, patrickk  wrote:

>
> hi everyone,
>
> I just wanted to outline a basic idea in order to improve (at least
> from my point of view) the index-page of the admin-interface. I don´t
> have any code to share (so far), so I´m basically explaining my idea -
> if people agree that this is useful, I´m trying to submit a patch.
>
> here´s the idea: currently, the admin index page is strictly coupled
> to the settings-file of my project (the INSTALLED_APPS). to me, that
> doesn´t seem the best way. a while ago, the admin-definition for apps
> has been coupled to the model-definition ... now there is a file
> called admin.py, which is much better IMHO. so why don´t we have a
> file admin.py for every project? within that file, one could define
> which apps (from INSTALLED_APPS) should be visible at the admin index
> page. moreover, the possibility to reorder/rearrange the way these
> apps are shown would be great.
> e.g, when I´m using djangos auth-app and I´m extending the user-model
> with a user-profile, I´m having "auth" (with users and groups) and
> "user" (with user profile) on my admin index page. orderd by names,
> auth is very much on the top of my page while user is at the bottom.
> for an editor, this is probably hard to understand (because the editor
> doesn´t know anything about apps). for an editor, it´d more
> comfortable having a headline "user management" with the apps "users",
> "groups" and "user profiles". this re-arrangement could be defined in
> admin.py.
>
> I hope this is somehow understandable. it´s a bit hard to explain in a
> foreign language ... it´d be great to hear other opinions.
>
> thanks,
> patrick


I think this sounds like a good idea. This was one of the first things I
wanted to do when getting started with the admin app.

--~--~-~--~~~---~--~~
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: #4926, Ordering in admin listview ignores ordering in admin options

[Joshua Russo]

On Fri, Sep 4, 2009 at 11:34 AM, Russell Keith-Magee  wrote:

>
> On Thu, Sep 3, 2009 at 12:07 PM, bendavis78 wrote:
> >
> > This issue has been up with a patch for quite awhile,  and wanted to
> > get some feedback from some devs on this.   The fix is pretty simple,
> > and seems to work ok for me.
> >
> > Here's my thoughts on it:  When I specify ordering with multiple
> > fields on my Model or my ModelAdmin, the changelist should respect
> > that ordering by default.  If the user changes the ordering using the
> > column headers, then it should use that ordering on the single field.
> > I don't I see why it should only be one or the other.
> >
> > I know there's another discussion going on about adding multiple field
> > ordering to the UI,  but that's a much bigger change.  Is there any
> > reason why this can't make it into trunk in the meantime?
>
> There are at least 3 reasons:
>
> 1) When you make a small change that fixes 50% of the problem, you
> remove 90% of the incentive to fix the problem properly.
>
> 2) Implementing, reviewing, and committing a patch takes time. Time
> spent fixing a small version of the problem is time that could have
> been spent fixing the big problem.
>
> 3) Sometimes (although probably not in this case) implementing a
> partial solution can box us into a corner regarding potential
> solutions to the big problem. By implementing a partial solution, we
> introduce something that we need to maintain for backwards
> compatibility purposes.
>
> The only real reason to make an exception is if the small change will
> prevent data loss, or if the status-quo is fundamentally unusable. In
> these cases, it makes sense to implement a partial solution in the
> interests of correcting the breakage. However, this classification
> doesn't apply here. The current ordering limitations are an annoyance,
> but not a critical failing.
>
>
I submitted a more thorough patch not too long ago but it needs regression
tests. I'm not sure how exactly to test something like this.

http://code.djangoproject.com/ticket/11695

Any thoughts?

--~--~-~--~~~---~--~~
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: Do you like #11834 "Colorized technical_500_response: django code is green, user code is red."?

[Joshua Russo]

On Sat, Sep 5, 2009 at 4:14 PM, Yuri Baburov  wrote:

>
> Hi devs,
>
> I published http://code.djangoproject.com/ticket/11834
> Screenshot:
> http://code.djangoproject.com/attachment/ticket/11834/11834.png
>
> I consider it pretty useful and it has saved me few hours of debugging
> already by its visual aid.
> But I'd like to hear what do you think of it.


I think this would be a great addition. Almost every time I receive an error
page one of the first things I do is to go to the stack trace and determine
where my code starts and Django's stops (or vice-versa).

Of course it looks like it will show any other app (other than Django) as
"user" code but I think that's ok. It at least separates the Django code
from everything else, which gets clean division 99% of the time. I like it.

--~--~-~--~~~---~--~~
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: Change list default sort modification proposal

[Joshua Russo]

Sorry for dragging this back out of the depths but I was reviewing my
code for regression testing and I noticed I had missed this comment
way back when.

Where is this named sort option documented?

It seems to me that the implementation that I have here would still be
useful even if you could associate multiple sort columns with a single
displayed column. I think that it's confusing to the developer not to
have the list display using the sort order that is defined within the
model.


On Aug 13, 2:49 pm, Rock  wrote:
> My suggestion for handling the UI for multi-column sorts is to allow
> the definition
> of named sorts in a manner similar to the way that the default sorting
> is defined.
> With this in place, additional multi column orders can be accomplished
> simply
> by using this name as a sort selection and applying the corresponding
> named sort.
>
> If this is an acceptable approach, I can flesh out the API for it.
>
> On Aug 11, 10:10 pm, Malcolm Tredinnick 
> wrote:
>
>
>
> > For those, like me, wondering what this proposal was about, it's
> > concerning changing sorting in the admin interface to initially use the
> > full set of fields specified in Meta.ordering on the model.
>
> > What I can't work out yet, due to difficulty in reviewing the patch,
> > mentioned below, is whether it allow sorting by more than one column via
> > the column-clicking method. That would almost certainly seem to be a
> > request that is going to arrive 10 seconds after a feature like this is
> > committed, although the difficulty has always been with how the UI works
> > for that situation.
--~--~-~--~~~---~--~~
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: Change list default sort modification proposal

[Joshua Russo]

I don't have any say in what gets accepted or not but I do believe that your
solution is a decent one. I'm continuing with mine because it addresses a
current need simply and can be (fairly) easily tested. If you can create the
regression tests for yours then I believe you might get more traction.
Then again there may be some hesitation to the level of complexity you are
introducing. There is always a strong inclination in the the project for
simplicity.


On Thu, Sep 17, 2009 at 5:42 PM, Ben Davis  wrote:

> I'm not sure if anyone's seen this,  but I've written a patch for
> multi-sort columns in the changelist ui here:
>
> http://code.djangoproject.com/ticket/11868
>
> Not sure if this is what you guys had in mind, but I'd be interested in
> your feedback.
>
>
> On Thu, Sep 17, 2009 at 12:57 PM, Joshua Russo wrote:
>
>>
>> Sorry for dragging this back out of the depths but I was reviewing my
>> code for regression testing and I noticed I had missed this comment
>> way back when.
>>
>> Where is this named sort option documented?
>>
>> It seems to me that the implementation that I have here would still be
>> useful even if you could associate multiple sort columns with a single
>> displayed column. I think that it's confusing to the developer not to
>> have the list display using the sort order that is defined within the
>> model.
>>
>>
>> On Aug 13, 2:49 pm, Rock  wrote:
>> > My suggestion for handling the UI for multi-column sorts is to allow
>> > the definition
>> > of named sorts in a manner similar to the way that the default sorting
>> > is defined.
>> > With this in place, additional multi column orders can be accomplished
>> > simply
>> > by using this name as a sort selection and applying the corresponding
>> > named sort.
>> >
>> > If this is an acceptable approach, I can flesh out the API for it.
>> >
>> > On Aug 11, 10:10 pm, Malcolm Tredinnick 
>> > wrote:
>> >
>> >
>> >
>> > > For those, like me, wondering what this proposal was about, it's
>> > > concerning changing sorting in the admin interface to initially use
>> the
>> > > full set of fields specified in Meta.ordering on the model.
>> >
>> > > What I can't work out yet, due to difficulty in reviewing the patch,
>> > > mentioned below, is whether it allow sorting by more than one column
>> via
>> > > the column-clicking method. That would almost certainly seem to be a
>> > > request that is going to arrive 10 seconds after a feature like this
>> is
>> > > committed, although the difficulty has always been with how the UI
>> works
>> > > for that situation.
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

An issue with ticket system

[Joshua Russo]

I just tried to update a patch on a ticket that I had created but the file I
uploaded isn't displaying. It shows in the list and with the correct file
size but when I try to view the file it's empty. I've upload quite a few
patches previously so I'm pretty sure it's not my process.
http://code.djangoproject.com/ticket/11695

here is the diff that I'm trying to upload
http://dpaste.com/hold/95397/

Any suggestions?

--~--~-~--~~~---~--~~
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: An issue with ticket system

[Joshua Russo]

On Fri, Sep 18, 2009 at 9:48 PM, Alex Gaynor  wrote:

>
> On Fri, Sep 18, 2009 at 6:44 PM, Joshua Russo 
> wrote:
> > I just tried to update a patch on a ticket that I had created but the
> file I
> > uploaded isn't displaying. It shows in the list and with the correct file
> > size but when I try to view the file it's empty. I've upload quite a few
> > patches previously so I'm pretty sure it's not my process.
> > http://code.djangoproject.com/ticket/11695
> > here is the diff that I'm trying to upload
> > http://dpaste.com/hold/95397/
> > Any suggestions?
> > >
> >
>
> If you press the original format button you will see that the patch is
> still there, trac just can't display all diffs (it's a very special
> piece of software).
>

Ah thanks, missed that little link there. I just wanted to make sure people
could see it.

--~--~-~--~~~---~--~~
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: django + couchdb

[Joshua Russo]

On Sat, Sep 19, 2009 at 8:08 AM, Suno Ano  wrote:

>
> Hi folks,
>
> I was wondering, are there any plans to support couchdb [0] as
> backend/database at some point? Some links I found in this regard are
>
>
>  - http://couchdbkit.org/docs/django-extension.html
>  - http://www.eflorenzano.com/blog/post/using-couchdb-django/
>
>
> Seems there are more and more folks getting the itch for non-SQL
> databases ...
>
>
> [0] http://en.wikipedia.org/wiki/Couchdb


There is an active branch working on non-relational DB support:
http://groups.google.com/group/django-developers/browse_thread/thread/410b69006addf41/651cf24fa24a2797#

Though
I'm not sure where it's housed.

--~--~-~--~~~---~--~~
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: Change list default sort modification proposal

[Joshua Russo]

Take a look in test\regressiontests\admin_views\tests.py
AdminViewBasicTest.testChangeListSortingXXX() methods. They should give you
a good place to start.

On Wed, Sep 23, 2009 at 6:18 PM, Ben Davis  wrote:

> I would write the tests though I'm not 100% sure how to write regression
> tests for a UI change...   any suggestions on how to go about doing that?
>
> On Thu, Sep 17, 2009 at 2:04 PM, Joshua Russo wrote:
>
>> I don't have any say in what gets accepted or not but I do believe that
>> your solution is a decent one. I'm continuing with mine because it addresses
>> a current need simply and can be (fairly) easily tested. If you can create
>> the regression tests for yours then I believe you might get more traction.
>> Then again there may be some hesitation to the level of complexity you are
>> introducing. There is always a strong inclination in the the project for
>> simplicity.
>>
>>
>> On Thu, Sep 17, 2009 at 5:42 PM, Ben Davis  wrote:
>>
>>> I'm not sure if anyone's seen this,  but I've written a patch for
>>> multi-sort columns in the changelist ui here:
>>>
>>> http://code.djangoproject.com/ticket/11868
>>>
>>> Not sure if this is what you guys had in mind, but I'd be interested in
>>> your feedback.
>>>
>>>
>>> On Thu, Sep 17, 2009 at 12:57 PM, Joshua Russo 
>>> wrote:
>>>
>>>>
>>>> Sorry for dragging this back out of the depths but I was reviewing my
>>>> code for regression testing and I noticed I had missed this comment
>>>> way back when.
>>>>
>>>> Where is this named sort option documented?
>>>>
>>>> It seems to me that the implementation that I have here would still be
>>>> useful even if you could associate multiple sort columns with a single
>>>> displayed column. I think that it's confusing to the developer not to
>>>> have the list display using the sort order that is defined within the
>>>> model.
>>>>
>>>>
>>>> On Aug 13, 2:49 pm, Rock  wrote:
>>>> > My suggestion for handling the UI for multi-column sorts is to allow
>>>> > the definition
>>>> > of named sorts in a manner similar to the way that the default sorting
>>>> > is defined.
>>>> > With this in place, additional multi column orders can be accomplished
>>>> > simply
>>>> > by using this name as a sort selection and applying the corresponding
>>>> > named sort.
>>>> >
>>>> > If this is an acceptable approach, I can flesh out the API for it.
>>>> >
>>>> > On Aug 11, 10:10 pm, Malcolm Tredinnick 
>>>> > wrote:
>>>> >
>>>> >
>>>> >
>>>> > > For those, like me, wondering what this proposal was about, it's
>>>> > > concerning changing sorting in the admin interface to initially use
>>>> the
>>>> > > full set of fields specified in Meta.ordering on the model.
>>>> >
>>>> > > What I can't work out yet, due to difficulty in reviewing the patch,
>>>> > > mentioned below, is whether it allow sorting by more than one column
>>>> via
>>>> > > the column-clicking method. That would almost certainly seem to be a
>>>> > > request that is going to arrive 10 seconds after a feature like this
>>>> is
>>>> > > committed, although the difficulty has always been with how the UI
>>>> works
>>>> > > for that situation.
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: Proposal: Tutorial Refresh

[Joshua Russo]

On Sun, Oct 11, 2009 at 7:40 PM, Rajeev J Sebastian <
rajeev.sebast...@gmail.com> wrote:

>
> On Sun, Oct 11, 2009 at 10:07 PM, Zachary Voase
>  wrote:
> >
> > On 11 Oct 2009, at 16:09, Alex Gaynor wrote:
> >
> >> I don't want to be overly negative, but in my view rewriting the
> >> tutorial would be a pointless waste of energy.  It has served us
> >> exceptionally well over the past 4 years, and none of the problems
> >> with it are fundamental, we'd be far better served by working to
> >> improve it, by adding more stages, than by rewriting it.  Further, I'd
> >> ague that the "staleness" of the tutorial is irrelevant, because the
> >> primary audience for the tutorial are precisely people who haven't
> >> seen it before.
> >>
> >> Alex
> >
> > I think I have to agree with Alex here. I’ve taught Django to a couple
> > of people in the past, and I found that the tutorial (as it is) worked
> > perfectly as an introduction to the concepts behind Django. After the
> > tutorial, the Django Book[1] is the next natural step, and it provides
> > a very solid grounding in pretty much everything, from development to
> > deployment. To round it all off, Eric Florenzano’s ‘Django from the
> > Ground Up’ showed them how to put what they had learned into practice.
> >
> > If there’s one thing *at all* that we should do, it’s add a chapter on
> > testing to the Django Book, and perhaps another section in the
> > tutorial devoted to it. But a comprehensive rewrite of the tutorial
> > seems completely unnecessary.
>
> +1
>
> I've trained 8 apprentices over the past 1-1/2 years. The existing
> django tutorial is invaluable since it can be done in about a day.


How about the possibility of an advanced tutorial, to highlight more
advanced features.

--~--~-~--~~~---~--~~
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: Proposal: Tutorial Refresh

[Joshua Russo]

On Sun, Oct 11, 2009 at 11:15 PM, Russell Keith-Magee <
freakboy3...@gmail.com> wrote:

>
> On Mon, Oct 12, 2009 at 7:15 AM, Zachary Voase
>  wrote:
> >
> > On 11 Oct 2009, at 23:39, Joshua Russo wrote:
> >
> >> How about the possibility of an advanced tutorial, to highlight more
> >> advanced features.
> >
> > That's pretty much what the Django Book is for.
>
> No, it really isn't.
>
> Firstly, The Django Book is an excellent resource, but it's not part
> of the Django project itself. Django's documentation is Django's
> documentation. Jacob and Adrian (and others) have written an excellent
> book, and I have no objections to people suggesting that newcomers
> should read that book, but it isn't part of Django's documentation.
>
> Secondly, the Django Book isn't a tutorial. It's an excellent set of
> explanatory notes of some advanced features, but it isn't a
> walkthrough of a specific worked example.
>
> I aspire to Django having the best documentation of any product out
> there - open source or otherwise. Having a comprehensive tutorial is
> part of that. Django's tutorial has said "more coming soon" for over 4
> years, and there is a lot that could (nay, should) be explained in a
> tutorial that we simply don't cover at the moment.
>
> As for whether a complete rewrite is necessary - I'm happy to call
> that a bikeshed. The current tutorial has served us well for four
> years, but it is a simple example. If that simple example doesn't
> provide enough scope for improvement, and Rob et al can come up with a
> good replacement - one that starts equally simple, but can become
> complex over time - I'm happy to entertain that proposal.
>
> Rest assured, we're not going to replace a good tutorial with a bad
> one. The tutorial won't be replaced until it is a worthy replacement
> for what we already have.
>
> Yours,
> Russ Magee %-)


I think I really am a +1 on maintaining a simple tutorial like we have now.
I feel that people may get discouraged if they have to spend too much time
to get to the end of a big complex tutorial, when all they want to do is to
get their toes wet. There may be some fine tuning that can be done to the
current design or perhaps a different design that may be a better fit, but I
think we should keep the introduction concise.

Conversely, I also believe that there is a need to demonstrate more advanced
features of the framework. I haven't heard anyone say yea or nay to the
addition of an advanced tutorial that I briefly suggested, but I just wanted
to give a little more support to it.

Josh

--~--~-~--~~~---~--~~
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: Django 1.2 feature voting

[Joshua Russo]

On Tue, Oct 13, 2009 at 12:38 PM, Jacob Kaplan-Moss wrote:

>
> Hey folks --
>
> Like last time 'round, if you'd like to express an opinion about
> features for Django 1.2, go and vote:
>
>
> http://spreadsheets.google.com/ccc?key=0AtIlKMKDxMBpdGVPVXlTODVLeTBpNkdLd3hqZzdYR3c&hl=en
>
> I've reorganized the 1.2 feature list
> (http://code.djangoproject.com/wiki/Version1.2Features) into a
> spreadsheet, and added short codes so we can have a shortcut when we
> talk about things. I've put my votes, and comments, into that sheet,
> and I'd like to invite you to share yours.
>
> I'd like to ask committers and anyone else to send me their own rankings.
> The
> easiest way is just to copy the spreadsheet and send it to me when you're
> done, but if you're anti-google just email me something I can read with
> codes,
> scores, and any notes. I'll add other folks' rankings to the master page as
> I
> get 'em.
>
> Committers: please get me your thoughts ASAP. I'd like to have a draft
> feature list for 1.2 out by October 20th.
>
> Please use the standard +1/+0/-0/-1 ranking. In this case the scores
> have some additional meaning:
>
> +1 -- "Yes!"
>For "must-have" features.
>
>A +1 from a committer means that s/he will champion the feature, guide
>the implementor (or implement it personally), review the patch, and
> commit
>the feature personally.
>
>A +1 from a non-committer is an offer to personally work on the feature,
>or to help the person working on it by reviewing the patch, testing,
> etc.
>
> +0 -- "OK"
>
>For features that are a "good idea".
>
>A +0 from a committer means that s/he will not stand in the way of the
>feature, but also won't personally invest much effort in it.
>
> -0 -- "Meh"
>
>For features that don't seem all that hot.
>
>A -0 from a committer indicates disapproval, but that s/he won't argue
>against the feature if another committer approves it.
>
> -1 -- "No!"
>A strong vote against.
>
>A -1 from a committer essentially is a veto. No features will be checked
>in with a -1 vote from a committer; only if s/he gets talked up to a -0
>or better will the feature happen.
>
> Using these votes, we'll make lists of "high", "medium", and
> "low" priority, and "rejected" features. These lists will be based on the
> following criteria, but remember there's a holistic aspect to this process.
> We'll use the votes to draft a feature list, but we'll also open up the
> list
> for discussion and make changes accordingly.
>
> Jacob


What are the prospects for tickets that have patches and docs that are not
on this list? Forgive my ignorance. I went back through the Contributing to
Django page but I still don't quite understand.

I have about 6 tickets, some of which would qualify as bug fixes and others
as features. Most of them are sitting as unreviewed. Does that mean that
mean that they are just not that important for the current cycle or should I
have posted them on the wiki? I didn't want to be too overbearing, I am just
curious about the process. I understand that there are only so
many commiters with only so much bandwidth.

Thanks,
Josh

--~--~-~--~~~---~--~~
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: Feature lists for 1.2

[Joshua Russo]

On Fri, Oct 23, 2009 at 5:29 PM, Jacob Kaplan-Moss wrote:

>
> 2009/10/23 kmike :
> > Some features from wiki proposal page don't get their way to google
> > spreadsheet (ex: 2 cache-related proposals) and they are not mentioned
> > in the final features page neither in a list of accepted features nor
> > in a list of rejected features.
>
> That's because they were proposed too late and/or were not clearly
> specified.
>
> > I understand that there are some valid
> > reasons for that but, out of curiosity, what are their 'official'
> > status?
>
> Same as everything else: get the code done by December 22nd and it goes in.
>
> Jacob
>

So any tickets that have the full gambit of patch/docs/tests should make it
into 1.2?

Just trying to get a handle on how the process works.

Thanks
Josh

--~--~-~--~~~---~--~~
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: Feature lists for 1.2

[Joshua Russo]

On Fri, Oct 23, 2009 at 11:21 PM, Jacob Kaplan-Moss wrote:

>
> > So any tickets that have the full gambit of patch/docs/tests should make
> it
> > into 1.2?
>
> In theory. Keep in mind, though, that us committers have limited
> mental bandwidth so we can't absolutely promise to get to every single
> ticket.
>
> I'll do my best, of course, but at the end of the day I'm going to
> prioritize the features that the aggregate voice of the community
> seems to want most.


Gotcha, understood.

--~--~-~--~~~---~--~~
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: 1.2 Feature Suggestion

[Joshua Russo]

On Sun, Oct 25, 2009 at 11:48 PM, Dan  wrote:

> I think this is best done through a third party site.  Look at the success
>> of DjangoGigs.  I don't know that there's a de facto place to look for apps
>> yet, but I bet a winner will emerge in time.
>>
>> Tobias
>>
>>
> The problem I see with that is that we clearly *are* standardizing toward
> some third parties apps. Not strongly enough to commit them to contrib with
> all the duties it implies but still! I don't think the doc is doing enough
> to let newcomers have the best tools available for their Django development.
>
> Or maybe we can go the Wiki route and display on the front page "ORM,
> cache, elegant URLs, ..., plenty of third party apps [link to a wiki page]".
>
> That way, there would be very little burden for the core devs and page
> would evolve as the different tools emerge.


I think a Wiki page would be the best way to handle this. I agree that there
is a need to more actively advertise some of the more popular third party
apps for new comers but those apps don't follow our dev cycle, so having
them in our docs doesn't seem to make sense.

Josh

--~--~-~--~~~---~--~~
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: 1.2 Feature Suggestion

[Joshua Russo]

On Mon, Oct 26, 2009 at 12:30 AM, Russell Keith-Magee <
freakboy3...@gmail.com> wrote:

>
> A wiki page doesn't really solve the problem either. If you make it an
> exclusive list, someone has to decide who is on the list and who
> isn't. If you make it a comprehensive list, a wiki page will very
> rapidly become unusable due to the volume of reusable apps out there -
> wiki format doesn't provide a lot of creative options for
> indexing/organizing content on multiple axes.


That's a good point. You really do need a better way to manage a list of
that size. A wiki page is better used for less dynamic lists and
information.

--~--~-~--~~~---~--~~
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: HTML 5

[Joshua Russo]

On Mon, Feb 1, 2010 at 1:00 PM, Luke Plant  wrote:

> > When Django makes a move with regards to HTML4/XHTML/HTML5...
>
> Here are my current thoughts on that issue - in a slightly overstated
> tone... :-)
>
> == XHTML as text/html is just fine ==
>
> I happen to agree with Simon Willison's post a while back that said
> that XHTML has 'lost', and HTML4 is a better option for new projects.
>
> However, I contend that:
>
> Django's behaviour (outputting XHTML) combined with the normal usage
> (serving as text/html) isn't causing anyone *any* real problems. Loads
> of people are doing it, and browsers handle it just fine.
>
> (I have read and re-read Hickson's article [1], and can't find any
> real problems that affect us.  You only have problems if you try to
> switch to application/xhtml+xml, which is easy to solve: don't do
> that).
>
> Of course, I'm discounting as 'problems' things like personal
> preferences and clients who insist on both HTML4 and valid documents.
> In practice, the choice between HTML4 and 'XHTML as text/html' makes
> no real difference to end users.  It's just a holy war for developers,
> and developers' tools.
>
> Simon brought up that it makes us look out of date, and I agree, but
> so what?  Switching back to HTML4 is driven by the same kind of
> purity-beats-practicality, fashion-conscious silliness that made us
> all switch to XHTML in the first place.  (As a matter of interest,
> www.bbc.co.uk uses XHTML, and after trying to validate a dozen major
> sites that I visit regularly, it happens to be the only one that
> validates.  That probably says something - while the switch to XHTML
> may have been misguided in the first place, those who did so had high
> ideals and actually cared about validation, and so wrote their tools
> and systems accordingly.  You are more likely to be able to generate a
> valid web page if you depend on an XHTML stack).
>
> On the other hand, if we were outputting HTML4, it might cause
> *genuine* problems - e.g.  if you need XHTML in order to mix in MathML
> or SVG on some pages.
>
> In short: XHTML is not entirely pointless for some use cases, but
> there is definitely something much more pointless: switching perfectly
> functioning XHTML code to HTML4 just because the web fashion gurus say
> so.  I've already wasted enough of my life doing things like that.
>
> == Multiple output formats is hard and nasty ==
>
> The fundamental problem here is the need to output in multiple markup
> languages.  (The fact that HTML4 and XHTML are so similar doesn't
> actually help us - we have to recognise that they are different
> languages.  The only attempts so far to produce code that outputs both
> have been as ugly as sin, IMHO).  However, Django simply does not work
> at the level of abstraction that would allow multiple output
> languages.  We encourage the use of templates where developers must
> write raw XHTML.  We have gobs of internal code that builds up XHTML
> as strings.  This means that the design of *everything* in our output
> is oriented to a *single* markup language, and that language is XHTML.
> We have never attempted to be markup agnostic.
>
> Changing that assumption in an elegant way would require changing
> *everything* to use a markup agnostic output tree, which you would
> then render with different 'writers'.  (I'm thinking something like
> the way Pandoc and docutils work).  We would basically be throwing
> away the entire template system and all templates, and much more
> besides.
>
> Every other attempt to fix this is just patching up lots of different
> symptoms, and it gets ugly very quick, both for us and for Django
> developers.
>
> In turn, that solution would mean that re-usable apps would end up
> choosing either HTML4 or XHTML, because writing code that supports
> both would be so painful.  (If we have trouble convincing designers to
> write "" instead of "", what chance do we stand with " selfclosing %}>" ?)  Supporting multiple doctypes will produce a Babel
> situation.  We *have* to pick a common language if we want the re-
> usable app market to thrive, and we have already done so - it's XHTML.
>
> As well as templates, there are many other bits of code that hard-code
> XHTML problems, such as various plain text to HTML formatters, both
> inside and outside the Django code base.  This even includes Django
> dependencies - docutils outputs XHTML, and there doesn't seem to be a
> way to output HTML4, short of writing our own 'writer'.
>
> I have several bits of code that would require a lot of work to make
> them output HTML as well as XHTML, and would require coupling to the
> template system or something equally nasty.
>
> In fact, one bit of code is impossible to fix - it is related to a
> text editor in django-cms, and outputs XHTML when the data is saved.
> To be able to fix it, I need to know what doctype the HTML will
> eventually end up in, which is impossible.
>
> The only fix for stored, user provided HTML is to run

Re: Some bugs in manage multidb

[Joshua Russo]

On Wed, May 19, 2010 at 6:50 AM, Waldemar Kornewald wrote:

> Hi Russell,
>
> On May 18, 1:59 pm, Russell Keith-Magee 
> wrote:
> > On Tue, May 18, 2010 at 5:08 PM, Alberto Paro 
> wrote:
> > > I'm developing a big application that does some complex mixing of
> database:
> > > SQL and notSQL one.
> > > I'm using the multidb to manage all the stuff in a django manner, using
> > > routing to route items in MongoDB and Postgresql.
> > > Some bugs that I've discovered:
> >
> > As a point of order, when something we don't support doesn't work,
> > it's not a bug - it's a feature request.
>
> At least the ForeignKey bug could be seen as a real bug because it
> indeed doesn't use the correct backend. I'm sure you could reproduce
> the bug with some other primary_key field that requires backend
> interaction (e.g., DecimalField, though this might not make a nice
> primary key ;).
>
> > Some of this discussion has already happened. If you search the
> > archives, you will find many references to NoSQL support (Google
> > AppEngine and MongoDB are particular favorites). These discussions
> > have revealed that adding NoSQL support isn't just a matter of some
> > minor tweaks to AutoField handling; There are some major plumbing
> > changes that are required.
>
> Actually, I've finished the MongoDB backend and it works really well
> on Django-nonrel (the patch still hasn't been committed to Alberto's
> repository, though). For example, our website (http://
> www.allbuttonspressed.com/) which we originally wrote for the App
> Engine backend works unmodified on the MongoDB backend (including the
> admin UI, BTW) and of course it also works with the SQL backends. All
> this still only needs a few minor modifications to Django. Of course,
> a cleanup and refactoring of the ORM would be useful to make more
> advanced features like JOIN emulation possible (we haven't really
> finished that discussion, BTW).


Your solution may work for your situation but you still need to prove it in
the test suite, to ensure that it will work in all known scenarios. It's too
easy to step on the toes of existing logic.

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

Proposal: Editable Model AutoField

[Joshua Russo]

I've developed and I'm currently using a mod to allow auto-increment id
fields to be editable. I'm curious if I should produce a ticket to allow
this, or will it cause a problem on some DBMS I'm not aware of.

It's pretty simple really.

1) I check for the editable keyword in the constructor of the AutoField,
defaulting it to false.

2) If editable I return an integer form field in the formfield() method for
AutoField

3) In forms\models.py: save_instance() I include the AutoField if it is
editable and has data. This is where I'm not sure about different DBMSs.
This always includes the field in the update data, and if the field is
populated in the insert data. My system runs MySQL.Will other DBMSs bark if
this is done? (As an aside I realize looking at the current incarnation of
forms\models.py the logic will need to go into construct_instance())

I've done this because I have a data entry system that really should have an
auto-increment id but has existing data on paper and they previously managed
the id by hand.

Don't bother recommending other solutions to my problem, the entire system
is already in place. I know there are other ways around my problem.

Does anyone see a problem with this? Should I create an patch and tests?

Josh

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

Unit test problem with the aggregation fixture

[Joshua Russo]

I'm trying to test a patch I'd like to submit but the fixture in the
aggregation tests is failing on an integrity error. It looks like a problem
with the order of the data, where a child table is being loaded before a
parent. I fixed the order and then received the same type of error from the
parent data because it contains a circular reference on to itself. Is this
the accepted behavior for the loaddata command? Does the data have be in the
proper order and non self-referential?

Josh

-- 
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: Unit test problem with the aggregation fixture

[Joshua Russo]

On Thu, Aug 26, 2010 at 9:11 PM, Karen Tracey  wrote:

> On Thu, Aug 26, 2010 at 6:05 PM, Joshua Russo wrote:
>
>> I'm trying to test a patch I'd like to submit but the fixture in the
>> aggregation tests is failing on an integrity error. It looks like a problem
>> with the order of the data, where a child table is being loaded before a
>> parent. I fixed the order and then received the same type of error from the
>> parent data because it contains a circular reference on to itself. Is this
>> the accepted behavior for the loaddata command? Does the data have be in the
>> proper order and non self-referential?
>>
>
> Depends on the database. MySQL/InnoDB can't handle forward references. See:
> http://code.djangoproject.com/ticket/3615.
>

Thanks Karen

-- 
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: Proposal: Editable Model AutoField

[Joshua Russo]

On Thu, Aug 26, 2010 at 11:37 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Fri, Aug 27, 2010 at 2:28 AM, Joshua Russo 
> wrote:
> > I've developed and I'm currently using a mod to allow auto-increment id
> > fields to be editable. I'm curious if I should produce a ticket to allow
> > this, or will it cause a problem on some DBMS I'm not aware of.
>
> The problem will come with databases that rely on the integrity of the
> sequence allocation process.
>
> For example, under Postgres, the primary keys are allocated from a
> sequence; if you manually allocate a primary key that uses a value in
> the sequence, and then you allocate objects that auto-fills the
> primary key value, eventually the already-used primary key will be
> offered as a candidate for the primary key. This will result in either
> a database error (because of a duplicate key) or worse -- overwriting
> the old row in the database.
>
> It's for this reason that Django has the 'sqlsequencereset' management
> command, and that the fixture loading tools reset sequences once
> fixtures have been loaded.


Ok, that's what I needed to know. I won't do anything with it then. Thanks

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