Should PlatPageSitemap show only public pages by default

[Peter]

In http://code.djangoproject.com/ticket/11358 a user complains about
that FlatPageSitemap defaults to show all pages including those which
require registration.

Easilly solved but is it a good default or should the solution just be
documented better or leave everything as it is?
I know that hiding private pages is somewhat like "security by
obscurity" but it might be a more sensible default.

Should I try to patch the docs or code or just close the ticket?

Peter M

--~--~-~--~~~---~--~~
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: Congratulations Alex and Russell on committing multidb!

[Peter]

I just noticed and can only agree... nice work.

//Peter

On Tue, Dec 22, 2009 at 18:27, Simon Willison wrote:

> And a big congratulations to all involved. Here's the changeset log
> (on GitHub since Trac seems not to like being linked to at the
> moment):
>
>
> http://github.com/django/django/commit/836d297e68d6a63103780295adebf6eaf6779611
>
> And here's the documentation:
>
> http://docs.djangoproject.com/en/dev/topics/db/multi-db/
>
> Really excited about this - can't wait to start putting it to good
> use.
>
> Cheers,
>
> Simon
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

--

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

Re: ModelForms and the Rails input handling vulnerability

[Peter]

Hi all,

Can I throw in option 5:

We leave ModelForms as they are, but emit a warning if you only partially 
render the form?

I'm not sure how feasible this is, but presumably we could keep track of 
which fields have been rendered for a given form instance?

That way, if you render the whole form ( {{ form.as_p }} ) you'll see your 
new sensitive field appear in the page. If you manually render the form, 
you'll get a warning.

One problem would be excessive warnings if you went further and hand craft 
the HTML - does anyone do that?

Cheers,

Peter

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

M2M with to_fields (ticket #18823)

[peter]

I opened this ticket (https://code.djangoproject.com/ticket/18823) on the 
Trac but thought i'd bring it up here to increase the likelihood of it 
getting noticed. In short things don't quite work right when you have a m2m 
field that uses a through model that uses a to_field for it's foreign 
key. If someone wouldn't mind reviewing the patch and giving me some 
feedback, I'd like to help get this issue fixed.

Assuming a fix in some form is accepted, I was also wondering if this bug 
fix would be considered important enough to backport to bugfix branches? Or 
will we need to wait for the next major release to get the fix in 
an official release.

Thanks for your time.

-- 
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/-/hHZ8EqEv_msJ.
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: M2M with to_fields (ticket #18823)

[peter]

The wrong rows being deleted is a possibility. Here's an example:

class Through(models.Model):
two = models.ForeignKey('Model2', to_field='spot')
one = models.ForeignKey('Model1')

class Model1(models.Model):
name = models.CharField(max_length=100)

class Model2(models.Model):
spot = models.IntegerField(unique=True)
ones = models.ManyToManyField(Model1, through=Through)

# Create objects and relations
m = Model1(name='test')
m2 = Model2(spot=2, pk=1)
m3 = Model2(spot=1, pk=2)
m.save()
m2.save()
m3.save()
Through(two=m2, one=m).save()
Through(two=m3, one=m).save()

# Both have ones
m2.ones.all()
m3.ones.all()

m2.ones.clear()

# Still has ones, didn't get deleted when it should have
m2.ones.all()

# This got deleted instead
m3.ones.all()

It's not exactly a real world example though i think it demonstrates that 
data loss is a possibility.

Monday, August 27, 2012 5:33:03 PM UTC-7, Russell Keith-Magee wrote:

> On Tue, Aug 28, 2012 at 3:11 AM, peter > 
> wrote: 
> > I opened this ticket (https://code.djangoproject.com/ticket/18823) on 
> the 
> > Trac but thought i'd bring it up here to increase the likelihood of it 
> > getting noticed. In short things don't quite work right when you have a 
> m2m 
> > field that uses a through model that uses a to_field for it's foreign 
> key. 
> > If someone wouldn't mind reviewing the patch and giving me some 
> feedback, 
> > I'd like to help get this issue fixed. 
> > 
> > Assuming a fix in some form is accepted, I was also wondering if this 
> bug 
> > fix would be considered important enough to backport to bugfix branches? 
> Or 
> > will we need to wait for the next major release to get the fix in an 
> > official release. 
>
> Generally speaking, we don't backport bug fixes unless they relate to: 
>
>  * Security issues 
>
>  * Major problems with newly added features 
>
>  * Problems with the potential to cause catastrophic data los -- i.e., 
> accidentally deleting/dropping data, or deleting/dropping the wrong 
> data. 
>
> A rule of thumb: If we'd discovered this feature the day before we cut 
> a major release, would we have held back the release? 
>
> In this case, it's not a security issue, and the code has had this 
> problem for several years; we certainly aim for being bug free, but 
> we've evidently survived with this bug for some time without any 
> serious problems. However, you *might* be able to make the case that 
> catastrophic data loss is possible. From an initial analysis, it seems 
> like it might be possible to accidentally delete the wrong through 
> model. If you can provide a clear example of a case where this would 
> happen, then yes, a backport is likely. 
>
> Yours, 
> Russ Magee %-) 
>

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

5 for 1?

[peter]

Not sure if this is still a thing, but i'd like to ask for a review of this 
ticket:

https://code.djangoproject.com/ticket/13794

I triaged/reviewed the following tickets: #18201, #19668, #19663, #19617, 
#19624

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

Re: 5 for 1?

[peter]

Thank you aaugustin for taking a look at 
https://code.djangoproject.com/ticket/13794. I've made some further updates 
but haven't heard anything back in a few weeks. Even though the original 
ticket title and description makes it sound like a fairly minor bug I do 
want to point out that as with most to_field related bugs this has the 
potential to cause data corruption. I'm not sure that enough people have 
run into this to warrant 'Release Blocker' status but when it does hit it 
has pretty nasty consequences.

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

Formsets and tofields

[peter]

Hi everyone,

This is about ticket (https://code.djangoproject.com/ticket/13794) where 
inline formsets don't respect a foreign key's to_field. I've written about 
this issue before, even tried a 5 for 1 but I'm having a hard time getting 
feedback on it. This bug doesn't just affect django admin but any use of 
inline formsets based on a to_field.

This bug can cause data loss. If you are lucky you'll see the error that 
the original reporter posted in the ticket but If the value of the to_field 
happens to be the same as the primary key of a different row on the same 
table it will silently and irreparably replace your relationships. Leading 
to very hard to track down bugs and real data loss.

It's seems not many people use to_fields but it is an official feature that 
is currently seriously broken for inline formsets and would be really nice 
to get this fixed. There are two possible patches there and I am happy to 
put in the work to get a fix accepted. So if you are willing to review and 
work with me on it please let me know.

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

Re: Perception of attitude in tickets

[Peter]

I have a thought on an action we could take out of this that might be 
constructive. 

Would it be possible to customise trak at all to make the workflow clearer? 

I'm thinking if someone tries to open a ticket that was closed by a committer 
then they should get an intermediate page pointing them to this group and 
asking them to confirm before the ticket is reopened.

I don't know if Trak is customisable to that extent, or if this would even be 
effective, but it would be nice to get something out of this.

Thanks,
Pete

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

Re: Feature request: Abstract ManyToManyField

[Peter]

On Feb 6, 8:45 pm, Simon Meers  wrote:
> 2011/2/5 Carl Meyer 
> > Hi Mike,
>
> > On Feb 3, 4:36 pm, Mike Lindsey  wrote:
> > > I'm doing something with bidirectional ManyToManyFields, in a project
> > > I'm working on, that is resulting in duplicate attempts to create the
> > > intermediate tables.  I'm perfectly open to suggestions of "You're
> > > doing it wrong" if they come with advice on how to fix my problem,
> > > without losing the easy Admin insertion of the relationships (without
> > > resorting to InLines, which don't seem to play nicely at all with
> > > FieldSets).  Right now I'm getting around the problem by running
> > > syncdb, running dbshell to drop the table it complains about, and
> > > rerunning syncdb; repeating until syncdb finishes successfully.
>
> > > What would make this exceptionally easy, is if there was the option to
> > > set 'abstract=True' on second iteration of each of the
> > > ManyToManyFields, telling syncdb to not attempt to create it.
>
> > So what you're trying to do here is simply not supported. I'm guessing
> > you've already concluded as much. This means that, for now, there is
> > no good answer for you (that I'm aware of). Whatever hack or
> > workaround you are able to come up with is what you're gonna get.
> > Sorry.
>
> BTW the ticket for this is #897 [1] and there is a suggested
> workaround (explicit declaration of the 'through' table) which isn't
> *too* ugly and might help you in the short-term?
>
> Simon
>
> [1]http://code.djangoproject.com/ticket/897

Forgive me if I've missed the point (I didn't read the thread very
thoroughly) but does this snippet fit the bill?

http://djangosnippets.org/snippets/1295/

-- 
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: Wrong error message when user having is_staff=False tries to login to admin

[Peter]

I think some people seem to be confused about what is being asked for.

I think the suggestion is that you should get this new "not an admin
account" message iff
the provided username _and_ password are correct. If you don't have
permission, but
provide an incorrect password, then you still get the old message.

That way, you can only gain more information than with the current
system when you have
both a username and correct password. If an attacker has that
information, then frankly,
it's too late to be thinking about how to make things more secure.

Regards,

Peter

-- 
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: prefetch_related - new feature suggestion

[Peter]

I'd just like to chime in to say this should definitely be part of
core - it's a common requirement, and whilst it could be a third party
app, it certainly feels much more at home in core.

On Sep 27, 1:13 pm, Luke Plant  wrote:
> For me, QuerySet is at a level of abstraction where I don't think it
> guarantees a single query. We have quite a bit of precedent here I think:

I also agree on this - many ORMs give the option to fetch objects
using a separate select (I'm thinking for example hibernates
"FetchMode.SELECT"). I think if you explicitly use this then you
probably need to understand what it does like anything else.

I've only had a brief look at the patch, but no doubt even if it needs
some polish it'll be a good start!

-- 
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: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[peter]

+1 on pre_syncdb

On Tuesday, May 21, 2013 8:29:49 AM UTC-7, Shai Berger wrote:
>
> On Tuesday 21 May 2013, Donald Stufft wrote: 
> > I run migrations in test. How else will you know your db reflects 
> reality 
> > :/ 
> > 
>
> When you have a few hundred migrations, that's something you're willing to 
> do 
> in your CI server, but not on your development machine. 
>
> Shai. 
>

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

Response Fixes

[peter]

This is in reference to this ticket: 
https://code.djangoproject.com/ticket/17092

There is a patch there to fix the specific use case of needing to disable 
django's fix_location_header for certain responses in a CGI compliant 
environment. Because of the way that response_fixes work you can't just 
implement middleware to bypass them. So the patch in that ticket adds an 
attribute to the response object that allows that 'fix' to be bypassed when 
the handler processes the response. In that ticket aagustin brought up that 
this might be better fixed by removing response_fixes from the base handler 
and instead implementing them in common middleware making it easier to 
add/remove or customize on a project by project basis rather than adding 
attributes to the response object.

Before going any further I wanted to see what the preferred approach would 
be.

I see 4 options.

1) Remove the concept of response_fixes from base handlers entirely and 
re-implement what we currently have as middleware. This would break any 
customized handlers that may be relying on  response_fixes as well as the 
current redirect behavior for projects that aren't using common middleware.

2) Leave response_fixes as a feature of handlers but move the 
fix_location_header functionality into middleware only breaking 
applications that aren't using common middleware.

3) Apply the patch as is, address any future problems with response_fixes 
as they come up.

4) Do nothing, projects that want the CGI compliant behavior can hack 
django.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d7b08325-6809-4b63-a948-4963bd590d5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

admin - form instantiation add_view, change_view

[Peter Cicman]

Wouldn't it be handy to add get_form_instance function to ModelAdmin?
Currently there is function get_form, which actually returns
FormClass. This is then getting instantiated on several places.
Sometimes its important to have possibility to add some attribute to a
form / override some field choices, etc...

There are two ways how to do it now:
1.) copy / override both add_view, change_view - too much code
inside, not very handy, i think they should be split anyway.
2.) FakeForm class instanciated on __call__ (hacky)..

I think function get_form_instance(*args, **kwargs) returning the
instance of form called from add_view / change_view will be nice
solution.



--~--~-~--~~~---~--~~
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: admin - form instantiation add_view, change_view

[Peter Cicman]

Your re right, i we missed the third option. It is just happening, if
you wanna do something advanced, and pass some variable from admin to
form. I have to say i have to make form instance modifications twice a
month, mostly because of choices/queryset for a field. It is not
always possible to fake this.

On Sep 29, 10:12 am, Russell Keith-Magee 
wrote:
> On Tue, Sep 29, 2009 at 3:51 PM, Peter Cicman  wrote:
>
> > Wouldn't it be handy to add get_form_instance function to ModelAdmin?
> > Currently there is function get_form, which actually returns
> > FormClass. This is then getting instantiated on several places.
> > Sometimes its important to have possibility to add some attribute to a
> > form / override some field choices, etc...
>
> > There are two ways how to do it now:
> >    1.) copy / override both add_view, change_view - too much code
> > inside, not very handy, i think they should be split anyway.
> >    2.) FakeForm class instanciated on __call__ (hacky)..
>
> You've missed the third option: define your own form class. If you
> create your own ModelForm subclass based on the model you want to
> display in the admin, you can override or set whatever attributes you
> want, and then tell the ModelAdmin to use your custom form. No runtime
> modification of the form instance is required.
>
> Yours,
> Russ Magee %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: contrib.admindocs need some love.

[Peter Baumgartner]

On Thu, Aug 27, 2009 at 2:03 PM, Justin Lilly  wrote:
> Hey guys.
>
>  I started writing some docs for another developer today and hit a few
> issues with admindocs that I plan on sprinting on for DjangoCon. I'm
> hoping anyone else with complaints / ideas will voice up, though my main
> impetus for the post is to announce that I'm going to do it so I
> can't back out. ;)
>
> Things I plan to address:
>
> 1. No tests.
> 2. No docs.
> 3. You can't seem to cross-link to views without the link being
> app.package.func . I'd like to see it at least configurable.
> 4. ManyToManyFields don't show up.
>
> There's not a ton there, but worth sprinting on, imo. Any other ideas or
> changes you'd like to see in admindocs that I might be able to work on?
> Shout them out.
>

It may be out of your scope, but admindocs flat-out breaks with GIS
fields. http://code.djangoproject.com/ticket/7977

-- Pete

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

LDAP authentication backend

[Peter Sagerson]

Hello all,

I'm the author of Contrib-09/#11526[1], an LDAP authentication  
backend. I haven't posted about it before and I saw some questions in  
the voting sheet, so I thought I'd try to address them here.

My motivation for writing the backend is simply that I'm managing a  
server with a variety of services and I wanted to unify  
authentication. Of the five types of services I'm juggling--Drupal,  
DokuWiki, Trac, miscellaneous private scripts via Apache, and a Django  
app--only Django lacked robust LDAP authentication.[2] I noted that  
#2507[3] had been marked as accepted, pending an acceptable diff and  
that said diff did not appear forthcoming, so I decided to write a  
comprehensive solution and submit it for version 1.2.

Some of the voting feedback was wondering whether this implementation  
was sufficiently generic, or if LDAP deployments varied so much that  
it was futile to try to include support in Django. However, as I  
mentioned above, many applications contain generic LDAP authentication  
solutions (I'll also add Cyrus SASL, Moin, and Joomla to the list, off  
the top of my head). My solution is actually rather more generic than  
any others I've seen, primarily because it's written for a framework,  
so it's designed with Python hooks to modify and extend its behavior.

The trickiest part of LDAP interoperability is managing groups, as  
there isn't a single standard mechanism for grouping users. Most  
libraries have a somewhat awkward solution for handling different  
group types; since this implementation is for a framework, we have the  
luxury of providing a subclassing API to allow powerful customization.  
In practice, though, most grouping is handled by a small number of  
common mechanisms. This is of course reinforced by the fact that  
Apache, Cyrus SASL, and other crucial clients only support a limited  
set. I've provided implementations for the standard mechanisms that  
I'm aware of and additional mechanisms are very easy to add, either in  
the core, in individual projects, or by third-party extensions.

Having said all of that, I will point out that this is a piece of  
functionality that can live quite happily outside of Django core. If  
it is not accepted into contrib.auth, this seems like the most  
compelling reason. I know this consideration comes up frequently,  
although having looked through the submission guidelines, I didn't see  
any kind of policy statement regarding what sorts of things are  
appropriate for the core project and what should exist as a third- 
party package. Perhaps I overlooked it.

So the bottom line is that in addition to using this myself, I will  
gladly maintain it as an external package on PyPI if that's the best  
place for it. However, I offer it to the Django core project should  
you wish to incorporate this functionality.

Thanks,
Peter


[1] http://code.djangoproject.com/ticket/11526
[2] Okay, it's a little generous to call Drupal's module robust, but  
it's getting there.
[3] http://code.djangoproject.com/ticket/2507


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

Help me write tests for my patch on template rendering

[Peter Bengtsson]

(Sorry about the vague subject line)

I've written a patch that fixes this:
http://code.djangoproject.com/ticket/11421
But so far only for AttributeErrors. But I don't want to submit the
patch until I've got tests for it.

Can someone guide me through the jungle of Django tests to run and
write a test for this?
I figure the place to add test is:
trunk/tests/regressiontests/templates/tests.py

But how do I run these? It takes many many seconds to run the whole
suite.

--~--~-~--~~~---~--~~
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: Help me write tests for my patch on template rendering

[Peter Bengtsson]

On 21 Oct, 16:34, Jacob Kaplan-Moss  wrote:
> On Wed, Oct 21, 2009 at 9:29 AM, Peter Bengtsson  wrote:
> > But how do I run these? It takes many many seconds to run the whole
> > suite.
>
> Seehttp://ericholscher.com/blog/2009/oct/16/easy-running-django-test-suite/
> if you need help running the test suite.
>
> Remember: `runtests.py` uses the same mechanism as Django's `manage.py
> test` does. So just like in application tests, you can limit your
> tests to just a single app using `runtests.py `, so in your
> case `runtests.py templates` will run just the template tests.
>
Thanks Jacob. I didn't realise this was "an app".
On the case now!
> Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Help me write tests for my patch on template rendering

[Peter Bengtsson]

Thanks for the help. Patch uploaded
http://code.djangoproject.com/ticket/11421

On Oct 21, 6:49 pm, Peter Bengtsson  wrote:
> On 21 Oct, 16:34, Jacob Kaplan-Moss  wrote:> On Wed, Oct 
> 21, 2009 at 9:29 AM, Peter Bengtsson  wrote:
> > > But how do I run these? It takes many many seconds to run the whole
> > > suite.
>
> > Seehttp://ericholscher.com/blog/2009/oct/16/easy-running-django-test-suite/
> > if you need help running the test suite.
>
> > Remember: `runtests.py` uses the same mechanism as Django's `manage.py
> > test` does. So just like in application tests, you can limit your
> > tests to just a single app using `runtests.py `, so in your
> > case `runtests.py templates` will run just the template tests.
>
> Thanks Jacob. I didn't realise this was "an app".
> On the case now!
>
> > Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Oracle backend TextField unique=True error

[Peter Herndon]

Hi all,

I've run into a situation where syncdb produces an error on one of my models 
against Oracle, but not against Postgres.  Using Postgres, one can mark a 
TextField as unique=True, and syncdb works just fine.  Using Oracle, you get an 
error:

> cx_Oracle.DatabaseError: ORA-02329: column of datatype LOB cannot be
> unique or a
> primary key

The error is occurring for someone using some code of mine 
(django-ldap-groups), rather than something I'm seeing directly.  I don't 
currently have access to an Oracle instance to test against.  FWIW, I remember 
running into this sort of limitation back when I used Oracle a few years ago, 
any LOB field was basically opaque -- no indexing, no uniqueness, etc.

Is this limitation known?  Is this an error on my part, that I shouldn't be 
trying to mark a TextField as unique?  Or should this be something that should 
be specially handled by the Oracle backend somewhere?  If the latter, I'm happy 
to file a bug report.

Thanks very much for all your hard work in creating and improving Django, I 
really appreciate all your work, it's made my life much easier.

Regards,

---Peter Herndon

--

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: Oracle backend TextField unique=True error

[Peter Herndon]

On Dec 18, 2009, at 12:02 PM, Ian Kelly wrote:

> On Fri, Dec 18, 2009 at 9:00 AM, Peter Herndon  wrote:
>> Hi all,
>> 
>> I've run into a situation where syncdb produces an error on one of my models 
>> against Oracle, but not against Postgres.  Using Postgres, one can mark a 
>> TextField as unique=True, and syncdb works just fine.  Using Oracle, you get 
>> an error:
>> 
>>> cx_Oracle.DatabaseError: ORA-02329: column of datatype LOB cannot be
>>> unique or a
>>> primary key
>> 
>> The error is occurring for someone using some code of mine 
>> (django-ldap-groups), rather than something I'm seeing directly.  I don't 
>> currently have access to an Oracle instance to test against.  FWIW, I 
>> remember running into this sort of limitation back when I used Oracle a few 
>> years ago, any LOB field was basically opaque -- no indexing, no uniqueness, 
>> etc.
>> 
>> Is this limitation known?  Is this an error on my part, that I shouldn't be 
>> trying to mark a TextField as unique?  Or should this be something that 
>> should be specially handled by the Oracle backend somewhere?  If the latter, 
>> I'm happy to file a bug report.
> 
> This is known.  The Oracle notes [1] mention that TextFields cannot be
> indexed.  Since Oracle requires indexes for unique columns, this also
> means they cannot be unique, although we should probably make that
> explicit.  It may also be worthwhile to check for this when the models
> are validated.
> 
> Ian
> 
> [1] http://docs.djangoproject.com/en/1.1/ref/databases/#textfield-limitations
> 


Thanks much, Ian.

Hmm.  Speaking from the perspective of a user of a reusable third-party app, 
what I'd most like to have happen is, when I run syncdb, the model validation 
checks for this, notices it is a TextField and removes any index or unique, and 
prints a line telling me that it has done so.  That way, the syncdb has done as 
much as it can while inconveniencing me the least, yet still letting me know.

On the other hand, there's something to be said for just popping a more 
descriptive error message and stopping.  Wait for the user explicitly to choose 
how to repair the impossible-to-fulfill request to index the TextField, rather 
than guess at how to proceed.

But then there's the difference in database implementation.  That is, marking a 
TextField unique in Postgres is valid.  How should I, as a reusable app author, 
handle this issue?  Should I be checking for database type in my model code, 
and adjust the field definition accordingly? Should I just document the hell 
out of it and move on?  Or remove the unique, and default to the lowest common 
denominator?

Thoughts?

Thanks again,

---Peter

--

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: Oracle backend TextField unique=True error

[Peter Herndon]

On Dec 22, 2009, at 12:04 AM, Mario Briggs wrote:

> Hi Ian,
> 
> Ian Kelly wrote:
>> Not currently, no.  And if I were to put in some work on improving on
>> the Oracle backend's support for filtering on TextFields, I would
>> concentrate first on fixing the query so that it correctly compares
>> the entire TextField and not just the first 4000 characters.
>> Unfortunately, I don't think any function-based index will help with
>> that.
> 
> hmmm. I am thinking differently. I think most of these use-cases where
> someone is doing a value based look up on a 'Text' would be a
> situation similar to what Russ has in admin view - the type is not
> fixed, it is could be any one of the types. However it is definetly
> not 'length unlimited' and the modeler has a fair idea of what the
> broad upper limit would be.
> 
> I think if it is really length-unlimited, then automatically there
> shouldnt be a use-case to do a value based lookup or have a unique
> index for it (unless it is once in a blue-moon, anything really
> frequent and performance will not be usable).  Definetly there could
> be a valid need for a google-style search of the column and this is
> where DB2 and Oracle support 'Text' indexing of LOB columns.
> 
> Peter, maybe you can elaborate why you choose 'Text' and why you need
> an a unique index on it.
> 

I chose TextField in order to store long LDAP DN strings.  At my place of work, 
our LDAP has quite a bit of depth in the tree, and OU and CN names can be quite 
long, which result in some very long strings to store.  I could conceivably use 
a CharField with an extremely large max_length, say 1024 or 2048, but with 
TextField I don't need to worry about overrunning the max length.

The LDAPGroup model itself is a mapping between an LDAP OU group membership, 
and a django.contrib.auth.models.Group, used to associate a given Django group 
and the permissions assigned to it with any LDAP-authenticating user who 
belongs to the OU.  When an LDAP user logs in, their LDAP group memberships are 
checked.  If one of those groups is mapped to a Django group, then their Django 
user model is automatically assigned to the mapped Django group, thereby giving 
the user whatever access rights are assigned to the group.  

I marked the TextField unique in order to ensure that there is one and only one 
mapping instance per LDAP OU.  The LDAPGroup mapping instance can map a single 
LDAP OU to multiple Django Groups, but I wanted to make sure there was only one 
such mapping in order to avoid having to search through multiple mapping 
instances to find all the places where an OU might be used.  In this case, 
there's only one mapping per OU.

The system would work if I used CharField, but I might run into cases where the 
OU is longer than the max_length on the CharField.  The system would also work 
if I relaxed the unique constraint on the OU, but then the database table would 
have redundancies.

I realize I'm somewhat abusing the notion of a TextField at the database level. 
 In this case, I want to treat it like an unlimited length varchar.  Or, the 
mirror perspective, I want to be able to guarantee uniqueness of a CLOB.  I 
hadn't thought much about the limitations in Oracle's treatment of CLOBs, since 
I'm using Postgres myself, where this works.  

---Peter

--

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: Ticket #5025 - truncate filter, why hasn't it been accepted?

[Peter Landry]

On 12/30/09 1:02 PM, "Ian Kelly"  wrote:

> On Wed, Dec 30, 2009 at 10:25 AM, Nic  Pottier  wrote:
>> On Dec 30, 8:55 am, Alex Gaynor  wrote:
>>> I'd highly recommend watchinghttp://www.youtube.com/watch?v=tscMnoS4YU8in it
>>> this *exact* question
>>> comes up and Russ, Malcolm, and a few other people discuss the pros
>>> and cons of adding new template tags/filters.
>>> 
>>> Alex
>> 
>> Thanks, that's a useful link.  The relevant portion starts at ~15:00
>> for those that are interested.
>> 
>> But really, the sum total of that discussion with regards to truncate
>> seemed to be:
>>  1) truncate doesn't exist because it wasn't useful in Journalism
>>  2) you can add it yourself
>>  3) we cover 80/20
>> 
>> What it explicitly doesn't say is that there is a huge cost to having
>> a new filter in core.
>> 
>> Don't get me wrong, I absolutely agree on the 80/20 principle, and on
>> that a clean and simple interface is hugely valuable. (The PHP mess is
>> a clear counterpoint here)
>> 
>> But I disagree that truncate is somehow an esoteric filter.  RoR has
>> it, Smarty has it, as do countless others, it just isn't that
>> unusual.
> 
> What I haven't seen yet for this filter is a clear use case.  If
> you're just trying to get something working quickly, then slice is
> fine.  When you're ready to go back and do it right, then the optimal
> solution is to use CSS [1].  If you only want to truncate at word
> boundaries, then you'll just use truncate_words.  What requirement
> does a truncate filter satisfy that these other solutions don't?
> 
> [1] http://mattsnider.com/css/css-string-truncation-with-ellipsis/
> 
> Ian
> 

Hello,
To address specifically this point, I would suggest that there might be use
cases where CSS isn't available to accomplish truncation (non-HTML text
output). It would be hard predict with certainty every context in which a
django template will be rendered.

Peter

--

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: Ticket #5025 - truncate filter, why hasn't it been accepted?

[Peter Landry]

On 12/30/09 3:29 PM, "Alex Gaynor"  wrote:

> Ok, we get it, some people want this feature.  I'd like to kindly
> request that people just saying "+1" stop.  The number of people in
> this thread is minuscule compared to the size of the django user
> population, trying to extrapolate from 1, 10, or even 100 people in
> this thread to a large percentage of the community wants this is
> simply not possible.
> 
> The video I linked earlier had a critical point that I think a lot of
> people are missing, adding a single filter may not add a lot to the
> developer's burden directly but it impacts the perceptions (and
> realities) of what kinds of things are reasonable for inclusion in
> core.  The simple fact is some people want this, and some don't.  Not
> having this is not an intractable problem for people who need it, in
> fact it's a trivial one.
> 
> I don't really care whether this is included or not, but it seems to
> me that there's very little in terms of new ground in the discussion.
> 
> Alex

Sorry if this takes things too far off-topic, but what is the proper way to
express support for a feature/ticket then? If the original argument is "not
enough people want it", I think it's fair that people voice their support,
and most have included specific use cases. What is the alternative?

Peter

--

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: What The Enterprise wants from Django

[Peter Herndon]

On Jan 21, 2010, at 9:58 AM, Luke Plant wrote:

> On Tuesday 19 January 2010 21:26:17 Jacob Kaplan-Moss wrote:
> 
>> So there we are. This is very much a brain dump, and I don't really
>> expect any concrete action to result from it. However, I found some
>> really interesting stuff there, and I thought I'd share.
> 
> Thanks for your clarification elsewhere in this thread.
> 
> One question I have (for Jacob and anyone else with experience):
> 
> I would have guessed that a big issue with Django from an enterprise 
> perspective is its use of 'singletons'. Though we don't use that 
> terminology, we have dozens of them in the code - every other setting 
> we have implies the existence of a singleton, since the setting can 
> have only one value.  For example, EMAIL_BACKEND means that we have 
> one email component singleton which is used everywhere.  If you wanted 
> one set of views to use a different email backend, you are out of 
> luck.
> 
> The 'admin' app was the first major component to allow multiple 
> instances, but there are various other apps which might need this 
> change in theory.
> 
> How much is this an issue in practice?  

Speaking as a web developer using Django in a *very* enterprisey corporation, I 
will say this singleton issue has been a problem for me.  As a self-inflicted 
example, I wrote an LDAP backend that looks up the necessary settings from 
settings.py.  I need to rewrite it to store the settings in the db, because I 
need to be able to query multiple LDAP sources.  I run into similar issues with 
lots of different apps.  So yes, singletons are an issue for me.

The difference between ops settings vs. app settings has also been a problem.  
The lack of established, vetted best practices (for deployment, layout, 
everything Russ mentioned) also has bitten me regularly.  In part because I 
wind up spending a lot of time doing the research to figure out what I need to 
do, in part because the state of the art moves forward at a rapid pace.  But, 
to put it in perspective, I'm the only person who even *can* deploy a Django 
app at my place of work.  Which is not great, but I'm also a Linux sys-admin, 
so it is at least in my job description.  But none of my fellow SAs have any 
clue what to do to get stuff working on one of our corporate RHEL 5 boxen, and 
no inclination to learn.

Anyway, I'm glad to see this discussion taking place.  Django indeed has a 
sweet spot, and it isn't really for enterprise installations -- though it is 
*very* good in that sweet spot.  There are places where the early design 
decisions to favor convention over configuration impose a lack of flexibility 
in favor of simplicity.  A definite trade-off.  It makes it harder to use in 
places where flexibility and integration are required.

Here's a big question, though:  given that satisfying the enterprise crowd, of 
which I am an occasional part, will require additional "stuff" that may bring 
along with it additional complexity, making it potentially harder to get 
started for newbies, is that a direction that the project should head?  Is it 
worth satisfying the enterprise crowd to increase adoption, at the cost of 
turning into the kind of configuration hell that J2EE servers exemplify?  Or, 
more positively, is it possible to add the required enterprisey bits while 
still maintaining a certain level of simplicity?  Note that Django is already 
headed towards greater complexity (multi-db, email backends), due to 
requirements from the current community.

My two cents, appropriately adjusted for the current economic situation.

---Peter Herndon 

-- 
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: possible bug in count() in many_to_many relations?

[Peter Sagerson]

I don't think this is a bug; it's just telling you that you can't count the 
photos until the gallery is in the database. Try:

x = Gallery.objects.create()
x.photo_count()


On Jan 24, 2010, at 3:14 PM, x13 wrote:

> (sorry for my English mistakes)
> Hello all, I have a problem with the count() function when I try to
> use it in an empty many_to_many relationship. I have these models:
> 
> 
> class Photo(models.Model):
>   ...
> 
> class Gallery(models.Model):
>   ...
>   photos = models.ManyToManyField('Photo', related_name='galleries',
> verbose_name=_('photos'), null=True, blank=True)
> 
> def photo_count(self):
>   return self.photos.count()
> 
> 
> Then when I try to call photo_count() with an empty Gallery I got an
> exception
> 
 x = Gallery()
 x.photo_count()
> 
>  File "/usr/local/django/.../models.py", line 66, in photo_count
>return self.photos.count()
>  File "/usr/local/lib/python2.6/dist-packages/django/db/models/fields/
> related.py", line 612, in __get__
>target_col_name=qn(self.field.m2m_reverse_name())
>  File "/usr/local/lib/python2.6/dist-packages/django/db/models/fields/
> related.py", line 421, in __init__
>raise ValueError("%r instance needs to have a primary key value
> before a many-to-many relationship can be used." %
> instance.__class__.__name__)
> ValueError: 'Gallery' instance needs to have a primary key value
> before a many-to-many relationship can be used.
> 
> 
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 

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

Ticket disposal

[Peter Sagerson]

Hello,

I submitted a patch[1] for 1.2 which was not accepted and almost certainly 
won't be in the future. This is perfectly fine, but it would be nice to get the 
bug closed wontfix so we have some closure (people are still adding themselves 
to the cc field). I just moved it to the 1.2 milestone with the intention that 
it would get swept up in a 1.2 cleanup, but that was apparently not the correct 
approach, as it was immediately reverted. The documentation is clear that I 
can't close it myself. As it stands, this ticket threatens to linger 
indefinitely. Can anyone advise on the correct procedure here?

Thanks,
Peter


[1] http://code.djangoproject.com/ticket/11526

-- 
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: Ticket disposal

[Peter Sagerson]

Thanks, Joseph.

I agree it works well as an external project. It's been on pypi for a little 
while[1] and I added the link again to the bottom of the (now closed) ticket. 
Incidentally, #2507[2] is a rather old and dusty ticket on the same subject.

Thanks,
Peter

[1] http://pypi.python.org/pypi/django-auth-ldap/
[2] http://code.djangoproject.com/ticket/2507


On Mar 2, 2010, at 2:53 PM, Joseph Kocherhans wrote:

> 
> On Mar 2, 2010, at 4:28 PM, Peter Sagerson wrote:
> 
>> Hello,
>> 
>> I submitted a patch[1] for 1.2 which was not accepted and almost certainly 
>> won't be in the future. This is perfectly fine, but it would be nice to get 
>> the bug closed wontfix so we have some closure (people are still adding 
>> themselves to the cc field). I just moved it to the 1.2 milestone with the 
>> intention that it would get swept up in a 1.2 cleanup, but that was 
>> apparently not the correct approach, as it was immediately reverted. The 
>> documentation is clear that I can't close it myself. As it stands, this 
>> ticket threatens to linger indefinitely. Can anyone advise on the correct 
>> procedure here?
> 
> Hey Peter. Did you ever end up making an external project for your LDAP 
> patch? If you did, it would be cool to have a link to it in the ticket. I 
> think a third party project is the best place for it. Feel free to close the 
> ticket and point to this thread or say "because jkocherhans said so" in the 
> comments. Pinging django-dev is probably the best way to handle stuff like 
> this.
> 
> I hope you have created or do create a project for it since there is 
> obviously interest. but since it can live outside of Django itself just fine, 
> it probably should. Sorry I didn't reply to you message awhile back [1].
> 
> Thanks,
> Joseph
> 
> [1] http://groups.google.com/group/django-developers/msg/8b354ab4e5d4724b
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 

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

Re: Django documentation for newer users

[Peter Herndon]

On Mar 5, 2010, at 11:35 AM, stherrien wrote:

> What I'm suggesting is that we setup something to allow everyone to
> improve the docs with help from the core django group. I think this
> would be very helpful to everyone. if one of the core group would like
> to help us get setup to do this it would be great. maybe if they setup
> a repository with the current online docs online so we can add updates
> as we do with django itself.


There are a couple of relevant pages on how to work with the documentation:

http://docs.djangoproject.com/en/1.1/internals/contributing/#documentation-style

http://docs.djangoproject.com/en/1.1/internals/documentation/#internals-documentation

Feel free to check out the project, make changes, file bug reports, and submit 
patches.  Documentation quality is taken pretty darned seriously, from what 
I've seen.

-- 
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: Process discussion: reboot

[Peter Landry]

On 4/19/10 10:19 AM, "Jacob Kaplan-Moss"  wrote:

> Hi folks --
> 
> I'd like to try to reboot the discussion that's been going on about
> Django's development process.
> 
> I'm finding the current thread incredibly demoralizing: there's a
> bunch of frustration being expressed, and I hear that, but I'm having
> trouble finding any concrete suggestions. Instead, the thread has
> devolved into just going around in circles on the same small handful
> of issues.
> 
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
> 
> Jacob

One suggestion that jumped out at me (which I admittedly know very little
history about with regards to Django or other projects) was the "trunk
ready" branch(es) [1]. Perhaps an effort to outline what that process might
entail in detail, to determine if it would address any concerns?

For my part, I see that it could be helpful to let some patches/ideas get a
shot at integration without having to endure the (necessarily) more rigorous
core commit trails.

I'm not really comfortable suggesting any concrete plans for how that might
happen though. A single almost-trunk branch? A branch per
lieutenant/component? I'm wary of adding too much bureaucracy and overhead.
I think it's pretty clear that the core Django process is successful, and
this seems like a low impact (though potentially high effort?) way to
involve more of the community.

Peter

[1] http://groups.google.com/group/django-developers/msg/ef8ec23d565dd07b

-- 
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: Process discussion: reboot

[Peter Landry]

On 4/19/10 11:41 AM, "Jacob Kaplan-Moss"  wrote:

> On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry  wrote:
>> One suggestion that jumped out at me (which I admittedly know very little
>> history about with regards to Django or other projects) was the "trunk
>> ready" branch(es) [1]. Perhaps an effort to outline what that process might
>> entail in detail, to determine if it would address any concerns?
> 
> FTR, I think this is a fine idea, and I think most (all?) of the other
> Django core developers do, too. It's just waiting on someone to Just
> Do It.
> 
> Anyone -- preferably a group -- who wants to start such a branch could
> go ahead and start one using the DVCS tool of their choice (Django has
> semi-official clones on Github, Bitbucket, and Launchpad). Tell me and
> I'll start watching it; show some continued motion and I'll spend some
> time getting a buildbot going against the branch; show high quality
> and I'll start pulling from it more and more frequently; show
> incredibly quality and I'll suggest that the maintainer(s) get commit.
> 
>> For my part, I see that it could be helpful to let some patches/ideas get a
>> shot at integration without having to endure the (necessarily) more rigorous
>> core commit trails.
> 
> Quality is important, and if this branch is created it needs to
> maintain that quality. If this hypothetical branch is low-quality it's
> just a different tool for a queue of un-reviewed patches, and I've
> already got one of those. I'm not willing to compromise on quality: if
> patches don't meet our standards, they don't go in.
> 
> Jacob

I fully agree regarding quality, my point being that this branch itself may
not be "trunk ready" at any given time, but patches/pulls from it would be;
quality of patches would obviously need to meet existing standards. Perhaps
that distinction isn't helpful, necessary, or desirable.

Peter

-- 
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: Process discussion: reboot

[Peter Baumgartner]

On Mon, Apr 19, 2010 at 8:19 AM, Jacob Kaplan-Moss  wrote:
> Hi folks --
>
> I'd like to try to reboot the discussion that's been going on about
> Django's development process.
>
> I'm finding the current thread incredibly demoralizing: there's a
> bunch of frustration being expressed, and I hear that, but I'm having
> trouble finding any concrete suggestions. Instead, the thread has
> devolved into just going around in circles on the same small handful
> of issues.
>
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
>

Jacob, I really think you're hearing from the vocal minority here.
There are plenty of people, myself included, who are very happy with
Django and the current development process. It will never be a perfect
fit for everyone and some will always complain. We've been using
Django professionally for a few years now and it has grown by leaps
and bounds in that time. I'm glad to see that Django is picky about
what is included. Stable growth trumps a kitchen sink worth of
half-baked features any day.

Keep up the amazing work and don't let the naysayers get you down.

-- Pete

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

django.db.models.Options contribute_to_class uses default connection instead of using DATABASE_ROUTERS

[Peter Long]

Hi Django developers,

I have been using the development copy of django from the svn trunk. I
think I may have found an area that needs updating now that django
supports multiple databases. I am not very familiar with the django
backend architecture so I am not sure if its a real bug or not and if
so how best to fix it. I would appreciate any input.

At the moment the file django/db/models/options.py has a method
contribute_to_class that is defined as:

def contribute_to_class(self, cls, name):
from django.db import connection

The imported connection is never used in the method, however if it
were used the code would be assuming that the model that is being
contributed to uses the default database. Perhaps that import should
be removed to avoid the temptation to use it and therefore force
developers to think about how to get a connection if one is needed.
Alternatively it could be changed to import the "connections"
dictionary and the "router" object. Something like:

def contribute_to_class(self, cls, name):
from django.db import connections, router
… code that initializes cls but does not need a connection …
db_name = router.db_for_read(cls)
connection = connections[db_name]
… code the needs a connection …

The reason I noticed this in the first place is because I applied the
patch that is part of ticket #6148 (http://code.djangoproject.com/
ticket/6148) to the latest trunk code and then defined two databases,
the default to hold the standard django tables in a local sqllite3
database and one to hold my legacy data on a db2 database with
multiple schemas. I noticed that my schema information was being
dropped from models defined as part of the db2 database. The reason
was that the patch code added to contribute_to_class that used the
connection was using the default database connection and not the db2
connection. As a result, since the patched sqllite instance does not
support schema's it was being dropped from my model's _meta data.
Applying the change described here solved the problem for this ticket.

This could conceivably be considered a bug in the patch for ticket
#6148, but I thought I would raise it here to see if anyone thought it
was something that should be fixed in the original source.

-- 
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: django.db.models.Options contribute_to_class uses default connection instead of using DATABASE_ROUTERS

[Peter Long]

> > The imported connection is never used in the method,
>
> Look closer - it is used, right at the end of contribute_to_class. The
> connection is used to get the operations module for the backend, which
> is then used to determine if the generated database table name needs
> to be truncated.

Oops. I thought that was part of the #6148 patch. :)

> Sounds like a bug in the patch to me. As I said earlier, the options
> class doesn't have any knowledge about the database that is being used
> for a specific operation, so it can't enforce per-database
> restrictions. In the case of db_table truncation, I suspect the right
> approach here is to store db_table as an untruncated string, and then
> truncate it at time of use inside specific backends or in queries. I
> suspect analogous changes will be required for #6148.
>
> This should also be logged as a bug; the truncation behavior that is
> currently implemented is definitely wrong.

Thanks for the information. I will log a bug regarding the db_table
truncation and reference this thread in it. Hopefully I will be able
to describe the problem adequately.

I will also raise the issue on ticket #6148. I have a feeling the code
contributed to this method by the patch for #6148 will just need to be
removed. The side effect being a lot of dependent code would need to
change. The patch adds what appears to be a convenience member called
qualified_name that is constructed by using another new member
db_schema and db_table. It calls
connections.ops.prep_db_table(self.db_schema, self.db_table) which
combines them in a db specific manner and qualified_name is set from
the resulting string. I am not sure where else this member could be
initialized where it would have access to the correct connection.
Sounds more likely that it must just be removed and constructed every
were a table name is needed. It occurred to me to turn qualified_name
into a "lazy loaded" member using a getter and a property(…) on
Options, but as you point out it still needs a connection and in
addition it appears the correct way to get a connection is to "ask" a
router what connection to use for a given Model instance. Since
Options is part of a Model instance's _meta instance I am not sure how
I would call router.db_for_read() from a Options getter method.

Peter Long

-- 
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: django.db.models.Options contribute_to_class uses default connection instead of using DATABASE_ROUTERS

[Peter Long]

On May 12, 8:54 am, Russell Keith-Magee 
wrote:
>
> FYI - I got itchy fingers, so I opened a bug report:
>
> http://code.djangoproject.com/ticket/13528
>
> Yours
> Russ Magee %-)

No problem. Thanks

Peter Long

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

Beating on an old issue; counter intuitive cascade deletes on foreign keys

[Peter Bengtsson]

I've now had to learn this the hard way by having real live data
deleted from my database on two production projects and it pisses me
off big time every time.

I can accept that NOT nullable foreign relations cascade the delete
but not if they have null=True on them. Example:

class Survey(Models):
...

class Analysis(Models):
survey = ForeignKey(Survey, null=True)

Just looking at that it's to be fairly obvious that on deleting a
Survey instance it should nullify the foreign key relation on the
Analysis model. Not delete it!


On a perhaps unrelated note is it a bug that I can't prevent this with
signals? This doesn't work:

def disconnect(sender, instance, **kwargs):
for each in Analysis.objects.filter(survey=instance):
each.survey = None
each.save()

pre_delete.connect(disconnect, sender=Survey)

-- 
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: Beating on an old issue; counter intuitive cascade deletes on foreign keys

[Peter Bengtsson]

On 8 June 2010 13:09, Jeremy Dunck  wrote:
> On Tue, Jun 8, 2010 at 7:30 AM, Peter Bengtsson  wrote:
>> I've now had to learn this the hard way by having real live data
>> deleted from my database on two production projects and it pisses me
>> off big time every time.
>>
>> I can accept that NOT nullable foreign relations cascade the delete
>> but not if they have null=True on them. Example:
>
> Actually, this looks to be fixed in 1.2.  What version are you
> running?  Closed ticket (with test cases) here:
> http://code.djangoproject.com/ticket/9308
>
I'm running Django 1.2.1 so perhaps it's not fixed.
Sigh. I have to make a test case to prove 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-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.
>
>



-- 
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
fun crosstips.org

-- 
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: Beating on an old issue; counter intuitive cascade deletes on foreign keys

[Peter Bengtsson]

Maybe the documentation is deliberately missing it because it's not
supposed to have to be documented since it's supposed to just work.
But as I'm suspecting, it doesn't.

On 10 June 2010 02:53, Thomas Guettler  wrote:
> The documentation says django emulates "ON DELETE CASCADE":
>   http://docs.djangoproject.com/en/dev/topics/db/queries/#deleting-objects
>
> But it is missing how to emulate ON DELETE SET NULL.
>
> In this thread Kevin Howerton posted an abstract base class to emulate ON
> DELETE SET NULL. But this does not work if you bulk delete with a query set.
>
> I opened a new ticket:
>
> http://code.djangoproject.com/ticket/13731
>
>  Thomas
>
> Russell Keith-Magee wrote:
>> On Wed, Jun 9, 2010 at 3:53 AM, Peter Bengtsson  wrote:
>>> On 8 June 2010 13:09, Jeremy Dunck  wrote:
>>>> On Tue, Jun 8, 2010 at 7:30 AM, Peter Bengtsson  wrote:
>>>>> I've now had to learn this the hard way by having real live data
>>>>> deleted from my database on two production projects and it pisses me
>>>>> off big time every time.
>>>>>
>>>>> I can accept that NOT nullable foreign relations cascade the delete
>>>>> but not if they have null=True on them. Example:
>>>> Actually, this looks to be fixed in 1.2.  What version are you
>>>> running?  Closed ticket (with test cases) here:
>>>> http://code.djangoproject.com/ticket/9308
>>>>
>>> I'm running Django 1.2.1 so perhaps it's not fixed.
>>> Sigh. I have to make a test case to prove it.
>>
>> Looking at Trac, #9308 was fixed in r10822, so it should be fixed in
>> 1.1, and it was ported back to 1.0.X as well.
>>
>> We pretty clearly document that our deletion scheme emulates "ON
>> DELETE CASCADE"; if you can provide evidence to the contrary, please
>> open a ticket.
>>
>> Yours,
>> Russ Magee %-)
>>
>
> --
> 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-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.
>
>



-- 
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
fun crosstips.org

-- 
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: Imports in the tutorial

[Peter Baumgartner]

On Thu, Jun 10, 2010 at 11:21 AM, Andrew Godwin  wrote:
> Hi all,
>
> I noticed today that the tutorial still does imports like "from
> mysite.polls.models import Poll", and URLs like "(r'^polls/$',
> 'mysite.polls.views.index')".
>
> At least in the places and projects I've worked with, the standard has been
> not to use the project name as part of the import, for various reasons:
>
>  - It makes apps more reuseable and not tied to the one project

In my experience, almost every project has domain-specific
applications that don't get reused. If you have a reusable app, you
bundle it separately (like South).

>  - It means you can't run two copies of the same application if they're
> direct neighbours (as, to get the imports running, you need to add the
> directory the project is contained in to the Python path, and thus you can't
> rename the directory from its import name).

Why do you need to change the Python path at all? Just drop your
project on the existing Python path and import from there. This is
easy enough with a symlink or better yet give it a setup.py and
install it like you would any other Python package.

>
> I realise both of these can be worked around (and I do a lot), but it would
> seem common sense to start encouraging people to do imports like "from
> polls.models import Poll" from day one. There might well be something I'm
> missing - please say - but this has bugged me for ages.
>

I agree that it is confusing that it will work either way, but I'd
argue in favor of using the project name everywhere. It is explicit
instead of mucking around with the Python path behind the scenes.

-- Pete

-- 
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: Imports in the tutorial

[Peter Baumgartner]

On Fri, Jun 11, 2010 at 9:16 AM, Andrew Godwin  wrote:
>
>
> On 11/06/2010 03:28, Peter Baumgartner wrote:
>>
>> In my experience, almost every project has domain-specific
>> applications that don't get reused. If you have a reusable app, you
>> bundle it separately (like South).
>>
>
> I entirely agree, but there's also a lot of domain-specific apps people make
> that get used in more than one project. If you're in the business of writing
> (say) CMS-backed sites, you're going to have a lot of apps matching that
> pattern, and as far as I'm aware, there's no downside to switching away from
> having project names in imports.
>
>> Why do you need to change the Python path at all? Just drop your
>> project on the existing Python path and import from there. This is
>> easy enough with a symlink or better yet give it a setup.py and
>> install it like you would any other Python package.
>>
>
> But that doesn't work. Say I have my nice shiny project "andrewblog". I want
> to deploy a staging version and a live version of this on my server.
>
> If I had local imports, I could just put both projects on the python path /
> install them / egg-link them, or whatever. But because they use module names
> for imports, if I install one site as a package "andrewblog" and the other
> as "andrewblog_staging", say, staging is actually going to be running off of
> the live models, URLs, etc, since it has code that goes "from
> andrewblog.posts.models import Post".

Why do your two sites need to share the same python path? Virtualenv
solves this problem quite gracefully.

-- Pete

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

ModelForms and ForeignKeys causing ValueError

[Peter Bengtsson]

I'm happy to submit a ticket but wanted to check first that I'm doing
the right thing. I think this used to work in Django 1.1 but not now
in trunk.

I can better explain it with code:

# models.py
class FooBarModel(models.Model):
name = models.CharField(max_length=10)
age = models.IntegerField()
user = models.ForeignKey(User)

# forms.py
class FooBarForm(forms.ModelForm):
class Meta:
model = FooBarModel

def __init__(self, *a, **k):
super(FooBarForm, self).__init__(*a, **k)
for field in self.fields:
self.fields[field].required = False

The point of this is that I can make an advanced search form where the
form is just like the form for added one of these models. In my view I
never call the save() method of the form instance.

# tests.py
class SimpleTest(TestCase):
def test_model_forms(self):
from forms import FooBarForm
post = {'name':'Peter'}
f2 = FooBarForm(data=post)
self.assertTrue(not f2.is_valid())


Instead of returning False on the is_valid() function, it raises a
ValueError which looks like this:

Traceback (most recent call last):
  File "/home/peterbe/dev/DJANGO/lc/debugapp/tests.py", line 14, in
test_model_forms
print f2.is_valid()
  File "/home/peterbe/virtualenvs/lc/lib/python2.5/site-packages/
Django-1.2.1-py2.5.egg/django/forms/forms.py", line 121, in is_valid
return self.is_bound and not bool(self.errors)
  File "/home/peterbe/virtualenvs/lc/lib/python2.5/site-packages/
Django-1.2.1-py2.5.egg/django/forms/forms.py", line 112, in
_get_errors
self.full_clean()
  File "/home/peterbe/virtualenvs/lc/lib/python2.5/site-packages/
Django-1.2.1-py2.5.egg/django/forms/forms.py", line 269, in full_clean
self._post_clean()
  File "/home/peterbe/virtualenvs/lc/lib/python2.5/site-packages/
Django-1.2.1-py2.5.egg/django/forms/models.py", line 317, in
_post_clean
self.instance = construct_instance(self, self.instance,
opts.fields, opts.exclude)
  File "/home/peterbe/virtualenvs/lc/lib/python2.5/site-packages/
Django-1.2.1-py2.5.egg/django/forms/models.py", line 51, in
construct_instance
f.save_form_data(instance, cleaned_data[f.name])
  File "/home/peterbe/virtualenvs/lc/lib/python2.5/site-packages/
Django-1.2.1-py2.5.egg/django/db/models/fields/__init__.py", line 416,
in save_form_data
setattr(instance, self.name, data)
  File "/home/peterbe/virtualenvs/lc/lib/python2.5/site-packages/
Django-1.2.1-py2.5.egg/django/db/models/fields/related.py", line 314,
in __set__
(instance._meta.object_name, self.field.name))
ValueError: Cannot assign None: "FooBarModel.user" does not allow null
values.


I can understand that the field doesn't like having None set as a
value because it will never allow the save but I'm not interested in
saving here. I'm interested in getting a form that models (no pun
intended) itself on a model.


So, bug or feature?

-- 
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: ModelForms and ForeignKeys causing ValueError

[Peter Bengtsson]

Submitted here: http://code.djangoproject.com/ticket/13776

On Jun 14, 2:05 pm, Karen Tracey  wrote:
> On Mon, Jun 14, 2010 at 12:39 PM, Peter Bengtsson  wrote:
> > I'm happy to submit a ticket but wanted to check first that I'm doing
> > the right thing. I think this used to work in Django 1.1 but not now
> > in trunk.
>
> > I can better explain it with code:
>
> > [snip details]
> > The point of this is that I can make an advanced search form where the
> > form is just like the form for added one of these models. In my view I
> > never call the save() method of the form instance.
>
> > # tests.py
> > class SimpleTest(TestCase):
> >    def test_model_forms(self):
> >        from forms import FooBarForm
> >        post = {'name':'Peter'}
> >        f2 = FooBarForm(data=post)
> >        self.assertTrue(not f2.is_valid())
>
> > Instead of returning False on the is_valid() function, it raises a
> > ValueError which looks like this:
>
> > [snip details]
>
> > I can understand that the field doesn't like having None set as a
> > value because it will never allow the save but I'm not interested in
> > saving here. I'm interested in getting a form that models (no pun
> > intended) itself on a model.
>
> > So, bug or feature?
>
> Looks like a bug to me. is_valid() ought not be raising a ValueError...worst
> case it should return False. But in this case True would seem to be the
> correct answer, since you've set the field to not required.
>
> 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.

Should it be possible to change mymodelforminstance.cleaned_data after having run mymodelforminstance.is_valid()?

[Peter Bengtsson]

I have a modelform where I change the cleaned_data dict after I have
run is_valid() and I'm not sure if this is the totally wrong way of
doing things or if it's a bug.
My code broke when I upgraded to 1.2 so it did work back in the 1.1
days.

# models.py
class Person(models.Model):
name = models.CharField()
age = models.IntegerField()
...

# forms.py
class PersonForm(forms.ModelForm):
class Meta:
model = Person

# views.py

form = PersonForm(data=request.POST)
form.fields['age'].required = False

if form.is_valid():
if not form.cleaned_data['age']:
form.cleaned_data['age'] =
_fetch_age_by_name(form.cleaned_data['name'])
assert form.cleaned_data['age']
person = form.save()   # FAILS!

Trying to run this fails with an IntegrityError or whatever it was
called because it can't save the form when the age field's valid is
None even though I have corrected the form data.

It smells to me like modelforminstance.save() needs to reconstruct the
instance from the cleaned_data again before committing.


PS. The temporary solution for other people getting stuck on this is
the following:

person = form.save(commit=False)
person.age = form.cleaned_data['age']
person.save()



-- 
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: Should it be possible to change mymodelforminstance.cleaned_data after having run mymodelforminstance.is_valid()?

[Peter Bengtsson]

On 16 June 2010 13:53, George Sakkis  wrote:
> On Jun 16, 4:22 pm, Peter Bengtsson  wrote:
>
>> I have a modelform where I change the cleaned_data dict after I have
>> run is_valid() and I'm not sure if this is the totally wrong way of
>> doing things or if it's a bug.
>> My code broke when I upgraded to 1.2 so it did work back in the 1.1
>> days.
>>
>> # models.py
>> class Person(models.Model):
>>     name = models.CharField()
>>     age = models.IntegerField()
>>     ...
>>
>> # forms.py
>> class PersonForm(forms.ModelForm):
>>     class Meta:
>>         model = Person
>>
>> # views.py
>>
>> form = PersonForm(data=request.POST)
>> form.fields['age'].required = False
>>
>> if form.is_valid():
>>     if not form.cleaned_data['age']:
>>         form.cleaned_data['age'] =
>> _fetch_age_by_name(form.cleaned_data['name'])
>>     assert form.cleaned_data['age']
>>     person = form.save()   # FAILS!
>
> Not sure why this fails but regardless, it's not good to have part of
> the validation logic outside the form. Instead define a clean() method
> in the form, move there the "if not ..." part and check if it also
> happens to solve the problem.
>

That' why I used django-developers instead of django-users. Perhaps
it's a bug and not a "user error".
This functionality has changed in 1.2 so it's not solid what should work how.



-- 
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
fun crosstips.org

-- 
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: Free SVN and Issue Tracker

[Peter Ma]

When I use google ajax search api,and got the key,use the example html.
javascript error

On 7/28/06, Deryck Hodge <[EMAIL PROTECTED]> wrote:
>
> On 7/27/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> >
> > FWIWwebfaction has offered this for a while for python
> > http://www.webfaction.com/freetrac
> >
> > BTW.. I can't see a reference to this on code.google.com
>
> It's http://code.google.com/hosting/.  I just added a project of my
> own to it, and it seems nice.
>
> Cheers,
> deryck
>
> --
> Deryck Hodgehttp://www.devurandom.org/
> Developer, Naples News http://www.naplesnews.com/
> Samba Team http://www.samba.org/
>
> >
>


-- 
www.mawei.name
Petit
IM&mail:[EMAIL PROTECTED]
13585201588

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

Feature Request: get_default_backend() in django.template.Engine

[Peter Thomassen]

Hi,

We're trying to create a template from string using 
DjangoTemplates.from_string() of the default template backend, which wraps the 
result of Engine.from_string() to construct an instance of the Template class 
defined in the backend definition file: django/template/backends/django.py#30

This Template class differs from the Engine-delivered Template in that it 
accepts a dictionary as the context, see 
https://docs.djangoproject.com/en/4.0/topics/templates/#django.template.backends.base.Template.render.

The default backend's engine is easily retrieved via 
django.template.Engine.get_default(). This function identifies the first 
configured DjangoTemplates backend, and then returns its .engine attribute. As 
a result, when from_string() is called, it will be called on the engine and not 
on the backend, thus the wrapping Template() call is missing.

I would like to propose adding a get_default_backend() function to 
django.template.Engine, which is like get_default(), but returns the backend 
itself (and not its .engine attribute). get_default() can then be adjusted to 
simply return get_default_backend().engine.

While trying to solve the issue (context argument type mismatch: dict vs 
Context), I found the docs not very helpful, as they are not very accurate in 
the distinction between a backend and its engine. I've also added a commit that 
clarifies that language.

I have submitted a patch here: https://github.com/django/django/pull/15944


FWIW, the problem can also be solved on the application layer, like:

def get_default_template_backend():
# Ad-hoc implementation of https://github.com/django/django/pull/15944
from django.template import engines
for backend in engines.all():
if isinstance(backend, DjangoTemplates):
return backend
raise ImproperlyConfigured("No DjangoTemplates backend is configured.")

However and IMHO, this needlessly duplicates the logic from get_default() and 
adds undue complication to the app (like having to know about and looping over 
the .all() iterable; raising the exception), whereas that complexity already is 
in the core.


Please let me know what you think!

Thanks,
Peter

--
https://desec.io/

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9f8d21ac-c963-6f43-2c19-f4fe8ff683e8%40desec.io.

#21978 include production-ready web server

[Peter Baumgartner]

Hi all! I'd like to re-open the discussion around
https://code.djangoproject.com/ticket/21978

As a "batteries included" framework, Django kind of leaves people to
fend for themselves when it comes to deployment. This makes it harder
than necessary for a developer to go from works-on-my-laptop to
works-on-the-internet. The docs here are great, but also daunting to a
newcomer https://docs.djangoproject.com/en/4.1/howto/deployment/

I'd love to see Django provide some sane defaults that people can use
to deploy a site without having to make a bunch of decisions they
don't totally understand.

I have two thoughts on how it could be handled:

1. Similar to the template backends. You get Django's template system
by default, but you're welcome to swap in Jinja2. I don't believe
there is a one-size-fits-all webserver, but probably a
one-size-fits-most.
2. Similar to cache/database backends. You define the backend you want
to use and Django makes some sane choices for you and allows you to
serve the site via some common `manage.py` command.

For the first option, Gunicorn is a popular choice, but afaik it does
not work on Windows. Waitress [1] is an interesting option for WSGI
serving and daphne exists for ASGI. Whitenoise is a reasonable choice
for serving static files. It doesn't yet support ASGI, but there has
been some activity on that front [2].

Thanks!

[1] https://pypi.org/project/waitress/
[2] https://github.com/evansd/whitenoise/pull/359

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6K9zk5PmcxYWXRdvco1pWXnO%2BHoYoYHf0pg5Mw%3DgmdefZArg%40mail.gmail.com.

Re: #21978 include production-ready web server

[Peter Baumgartner]

Thanks for the additional background Carlton! I like the idea of
having some sort of protocol that folks can follow to make
ready-to-use Django server packages (django-webserver [1] is in the
same vein), but I'd strive for more. pip install + INSTALLED_APPS is
great, but getting to production with that approach can feel like
death by a thousand paper cuts. Do that with gunicorn, whitenoise,
dj-database-url, etc. and it ends up being a laundry list of things
that, in my experience, people rarely get right on the first try and
just result in frustration.

It seems like part of the challenge here is reaching parity with the
current runserver command, but is that necessary? Running `runserver
--dev` locally and getting dev features like autoreloading and then
having `runserver` use a different server for a deployed app doesn't
seem unreasonable.

[1] https://github.com/lincolnloop/django-webserver

On Tue, Aug 23, 2022 at 10:14 AM Carlton Gibson
 wrote:
>
> Hey Pete.
>
> Yes... this is a good one.
>
> It's difficult to see how we can even have an ASGI runserver in core, simply 
> because there's no SimpleServer equivalent as there is for WSGI, and it's not 
> clear one is on the card. (HTTP is getting **more** complex, and I can't see  
> Python bringing such into the standard library.)
> So we have to use a third-party dependency for that.
>
> For the Channels v4 update (in progress now) I'm moving the runserver command 
> to the Daphne package. This was because folks wanted to use Channels without 
> the Daphne/Twisted dependency.
>
> See: https://github.com/django/daphne/pull/429
>
> tl;dr — it came out pretty clean TBH. You pip install daphne, then add 
> "daphne" at the top of INSTALLED_APPS. (There's a system check to make sure 
> you're not fighting staticfiles.)
>
> On the back of that I don't see why servers (any servers) can't provide a 
> runserver command (or a django-* mini-package to go with it) and offer what 
> they offer in development as well as production. (Obviously that all needs 
> writing but it's just a management command.)
>
> Related is strategising the reloader. 
> https://code.djangoproject.com/ticket/30213
>
> We could then host *Protocols* — "Your runserver should do this", "Implement 
> this for your reloader", and so on — and (maybe) (slowly) replace built-in 
> options here with either optional dependencies (pip install django["daphne"]) 
> or recommendations to get going. (pip install django["starter"] maybe). — I 
> don't know — we seem a long way from that. (I don't suppose wsgiref is going 
> anywhere too soon is it?)
>
> But to cut back to your point, I don't know that we need to **include** a 
> server — just make it easy to get going. These days pip install + a line in 
> INSTALLED_APPS doesn't seem too much to ask (I think.)
>
> Was it really 4 years ago Tom left that comment on #21978 😳 (We'd finally 
> close this as wontfix: Django doesn't ship a webserver.)
>
> Does that fit in your view, or would that scenario not be good enough?
>
> Kind Regards,
>
> Carlton
>
> On Tue, 23 Aug 2022 at 16:56, Peter Baumgartner  wrote:
>>
>> Hi all! I'd like to re-open the discussion around
>> https://code.djangoproject.com/ticket/21978
>>
>> As a "batteries included" framework, Django kind of leaves people to
>> fend for themselves when it comes to deployment. This makes it harder
>> than necessary for a developer to go from works-on-my-laptop to
>> works-on-the-internet. The docs here are great, but also daunting to a
>> newcomer https://docs.djangoproject.com/en/4.1/howto/deployment/
>>
>> I'd love to see Django provide some sane defaults that people can use
>> to deploy a site without having to make a bunch of decisions they
>> don't totally understand.
>>
>> I have two thoughts on how it could be handled:
>>
>> 1. Similar to the template backends. You get Django's template system
>> by default, but you're welcome to swap in Jinja2. I don't believe
>> there is a one-size-fits-all webserver, but probably a
>> one-size-fits-most.
>> 2. Similar to cache/database backends. You define the backend you want
>> to use and Django makes some sane choices for you and allows you to
>> serve the site via some common `manage.py` command.
>>
>> For the first option, Gunicorn is a popular choice, but afaik it does
>> not work on Windows. Waitress [1] is an interesting option for WSGI
>> serving and daphne exists for ASGI. Whitenoise is a reasonable choice
>> for serving static files. It doesn't yet 

Re: Feature Request: get_default_backend() in django.template.Engine

[Peter Thomassen]

Hi Carlton,

On Mon, Aug 22, 2022 at 6:21 AM Carlton Gibson  wrote:
The current get_default() behaviour was only added to allow folks manually creating `Template("My String")` instances to continue to operate with multiple Django backends defined (#27359) — the initial assumption there was that anonymous backend usage wouldn't be supported, i.e. that folks would do `engines["django"]` to get a specific backend.  Could you use that? 


Yeah, that works! Thank you for the hint.

The docs mention this functionality with the wrong wording, which is why I was 
not aware of this functionality:


Template engines are available in django.template.engines:

from django.template import engines

django_engine = engines['django']

template = django_engine.from_string("Hello {{ name }}!")

-- 
https://docs.djangoproject.com/en/4.0/topics/templates/#django.template.loader.engines

This is not accurate: `engines` ironically holds the template backends, not the 
engines, and each engine can be retrieved by calling .engine (such as 
engines['django'].engine).

In general, the docs are very inconsistent in this regard and use the terms "backend" and 
"engine" pretty much interchangeably. The code is naturally more strict, but the iterable 
holding the backends nevertheless is called `engines`.

If people feel this is a correct assessment, I can try improving on the wording.

Thanks,
Peter

--
https://desec.io/

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5232c741-8410-1bcc-62d0-3ee942b25ea2%40desec.io.

Re: #21978 include production-ready web server

[Peter Baumgartner]

I put together a first stab at this at
https://github.com/lincolnloop/django-production. Feedback is appreciated!

On Tue, Aug 23, 2022 at 1:34 PM pe...@lincolnloop.com 
wrote:

> I hadn't seen django-simple-deploy. At first glance, it looks interesting,
> but more platform-specific than what I was thinking.
>
> I'll play around with creating a third-party app that encapsulates some of
> these thoughts and see where I end up.
>
> Thanks for your time and feedback!
>
> On Tuesday, August 23, 2022 at 1:17:12 PM UTC-6 carlton...@gmail.com
> wrote:
>
>> Hey Pete.
>>
>> Yes, there can be a lot of steps... (and trouble is every one has a
>> different opinion once you get to specifics :)
>>
>> django-webserver looks good — in a similar ballpark to what I had in
>> mind, yes, but I'd probably not want to bundle the options for each server
>> myself, as that seems a lot to maintain over time... (Better to outsource
>> to the individual projects no?)
>>
>> Have you seen what Eric Matthes is doing with django-simple-deploy?
>>
>> https://github.com/ehmatthes/django-simple-deploy
>>
>> I really like the idea: in an opinionated way, it applies the project
>> changes you need to deploy (and it's plugable so folks could provide a
>> *template* for their own flavour of deployment if they wanted, which is
>> kind of important given the number of options in the landscape, even if you
>> only to *ship* a beginner option.)
>>
>> Tim Allen also recently raised improving the Django project template,
>> which I think is related here. (That's on my list too: async this QTR, then
>> hoping to take on Adam's proposal to modernise the Request object for the
>> end of year, then 🤞 swinging back here for "OK, what does it look like,
>> what can we do?" after that: there's a bunch of related tickets around
>> #21978 that it would be very sweet if we could clear up...)
>>
>> I think all these thoughts are really pursuable outside of core in the
>> very short run, even if the goal is to merge them — it's much easier to
>> experiment that way, and then say, "This worked".
>>
>> Anyhow, other than a "I've been thinking along these lines", and a
>> generally positive emote, I don't have too much more concrete at this
>> stage.
>> 👍
>> C.
>>
>> On Tue, 23 Aug 2022 at 19:00, Peter Baumgartner 
>> wrote:
>>
>>> Thanks for the additional background Carlton! I like the idea of
>>> having some sort of protocol that folks can follow to make
>>> ready-to-use Django server packages (django-webserver [1] is in the
>>> same vein), but I'd strive for more. pip install + INSTALLED_APPS is
>>> great, but getting to production with that approach can feel like
>>> death by a thousand paper cuts. Do that with gunicorn, whitenoise,
>>> dj-database-url, etc. and it ends up being a laundry list of things
>>> that, in my experience, people rarely get right on the first try and
>>> just result in frustration.
>>>
>>> It seems like part of the challenge here is reaching parity with the
>>> current runserver command, but is that necessary? Running `runserver
>>> --dev` locally and getting dev features like autoreloading and then
>>> having `runserver` use a different server for a deployed app doesn't
>>> seem unreasonable.
>>>
>>> [1] https://github.com/lincolnloop/django-webserver
>>>
>>> On Tue, Aug 23, 2022 at 10:14 AM Carlton Gibson
>>>  wrote:
>>> >
>>> > Hey Pete.
>>> >
>>> > Yes... this is a good one.
>>> >
>>> > It's difficult to see how we can even have an ASGI runserver in core,
>>> simply because there's no SimpleServer equivalent as there is for WSGI, and
>>> it's not clear one is on the card. (HTTP is getting **more** complex, and I
>>> can't see  Python bringing such into the standard library.)
>>> > So we have to use a third-party dependency for that.
>>> >
>>> > For the Channels v4 update (in progress now) I'm moving the runserver
>>> command to the Daphne package. This was because folks wanted to use
>>> Channels without the Daphne/Twisted dependency.
>>> >
>>> > See: https://github.com/django/daphne/pull/429
>>> >
>>> > tl;dr — it came out pretty clean TBH. You pip install daphne, then add
>>> "daphne" at the top of INSTALLED_APPS. (There's a system check to mak

Re: #21978 include production-ready web server

[Peter Baumgartner]

gt;> On Tue, Aug 23, 2022 at 1:34 PM pe...@lincolnloop.com <
>> pe...@lincolnloop.com> wrote:
>>
>>> I hadn't seen django-simple-deploy. At first glance, it looks
>>> interesting, but more platform-specific than what I was thinking.
>>>
>>> I'll play around with creating a third-party app that encapsulates some
>>> of these thoughts and see where I end up.
>>>
>>> Thanks for your time and feedback!
>>>
>>> On Tuesday, August 23, 2022 at 1:17:12 PM UTC-6 carlton...@gmail.com
>>> wrote:
>>>
>>>> Hey Pete.
>>>>
>>>> Yes, there can be a lot of steps... (and trouble is every one has a
>>>> different opinion once you get to specifics :)
>>>>
>>>> django-webserver looks good — in a similar ballpark to what I had in
>>>> mind, yes, but I'd probably not want to bundle the options for each server
>>>> myself, as that seems a lot to maintain over time... (Better to outsource
>>>> to the individual projects no?)
>>>>
>>>> Have you seen what Eric Matthes is doing with django-simple-deploy?
>>>>
>>>> https://github.com/ehmatthes/django-simple-deploy
>>>>
>>>> I really like the idea: in an opinionated way, it applies the project
>>>> changes you need to deploy (and it's plugable so folks could provide a
>>>> *template* for their own flavour of deployment if they wanted, which is
>>>> kind of important given the number of options in the landscape, even if you
>>>> only to *ship* a beginner option.)
>>>>
>>>> Tim Allen also recently raised improving the Django project template,
>>>> which I think is related here. (That's on my list too: async this QTR, then
>>>> hoping to take on Adam's proposal to modernise the Request object for the
>>>> end of year, then 🤞 swinging back here for "OK, what does it look like,
>>>> what can we do?" after that: there's a bunch of related tickets around
>>>> #21978 that it would be very sweet if we could clear up...)
>>>>
>>>> I think all these thoughts are really pursuable outside of core in the
>>>> very short run, even if the goal is to merge them — it's much easier to
>>>> experiment that way, and then say, "This worked".
>>>>
>>>> Anyhow, other than a "I've been thinking along these lines", and a
>>>> generally positive emote, I don't have too much more concrete at this
>>>> stage.
>>>> 👍
>>>> C.
>>>>
>>>> On Tue, 23 Aug 2022 at 19:00, Peter Baumgartner 
>>>> wrote:
>>>>
>>>>> Thanks for the additional background Carlton! I like the idea of
>>>>> having some sort of protocol that folks can follow to make
>>>>> ready-to-use Django server packages (django-webserver [1] is in the
>>>>> same vein), but I'd strive for more. pip install + INSTALLED_APPS is
>>>>> great, but getting to production with that approach can feel like
>>>>> death by a thousand paper cuts. Do that with gunicorn, whitenoise,
>>>>> dj-database-url, etc. and it ends up being a laundry list of things
>>>>> that, in my experience, people rarely get right on the first try and
>>>>> just result in frustration.
>>>>>
>>>>> It seems like part of the challenge here is reaching parity with the
>>>>> current runserver command, but is that necessary? Running `runserver
>>>>> --dev` locally and getting dev features like autoreloading and then
>>>>> having `runserver` use a different server for a deployed app doesn't
>>>>> seem unreasonable.
>>>>>
>>>>> [1] https://github.com/lincolnloop/django-webserver
>>>>>
>>>>> On Tue, Aug 23, 2022 at 10:14 AM Carlton Gibson
>>>>>  wrote:
>>>>> >
>>>>> > Hey Pete.
>>>>> >
>>>>> > Yes... this is a good one.
>>>>> >
>>>>> > It's difficult to see how we can even have an ASGI runserver in
>>>>> core, simply because there's no SimpleServer equivalent as there is for
>>>>> WSGI, and it's not clear one is on the card. (HTTP is getting **more**
>>>>> complex, and I can't see  Python bringing such into the standard library.)
>>>>> >

Re: #21978 include production-ready web server

[Peter Baumgartner]

ver looks good — in a similar ballpark to what I had in
>>>> mind, yes, but I'd probably not want to bundle the options for each server
>>>> myself, as that seems a lot to maintain over time... (Better to outsource
>>>> to the individual projects no?)
>>>>
>>>> Have you seen what Eric Matthes is doing with django-simple-deploy?
>>>>
>>>> https://github.com/ehmatthes/django-simple-deploy
>>>>
>>>> I really like the idea: in an opinionated way, it applies the project
>>>> changes you need to deploy (and it's plugable so folks could provide a
>>>> *template* for their own flavour of deployment if they wanted, which is
>>>> kind of important given the number of options in the landscape, even if you
>>>> only to *ship* a beginner option.)
>>>>
>>>> Tim Allen also recently raised improving the Django project template,
>>>> which I think is related here. (That's on my list too: async this QTR, then
>>>> hoping to take on Adam's proposal to modernise the Request object for the
>>>> end of year, then 🤞 swinging back here for "OK, what does it look like,
>>>> what can we do?" after that: there's a bunch of related tickets around
>>>> #21978 that it would be very sweet if we could clear up...)
>>>>
>>>> I think all these thoughts are really pursuable outside of core in the
>>>> very short run, even if the goal is to merge them — it's much easier to
>>>> experiment that way, and then say, "This worked".
>>>>
>>>> Anyhow, other than a "I've been thinking along these lines", and a
>>>> generally positive emote, I don't have too much more concrete at this
>>>> stage.
>>>> 👍
>>>> C.
>>>>
>>>> On Tue, 23 Aug 2022 at 19:00, Peter Baumgartner 
>>>> wrote:
>>>>
>>>>> Thanks for the additional background Carlton! I like the idea of
>>>>> having some sort of protocol that folks can follow to make
>>>>> ready-to-use Django server packages (django-webserver [1] is in the
>>>>> same vein), but I'd strive for more. pip install + INSTALLED_APPS is
>>>>> great, but getting to production with that approach can feel like
>>>>> death by a thousand paper cuts. Do that with gunicorn, whitenoise,
>>>>> dj-database-url, etc. and it ends up being a laundry list of things
>>>>> that, in my experience, people rarely get right on the first try and
>>>>> just result in frustration.
>>>>>
>>>>> It seems like part of the challenge here is reaching parity with the
>>>>> current runserver command, but is that necessary? Running `runserver
>>>>> --dev` locally and getting dev features like autoreloading and then
>>>>> having `runserver` use a different server for a deployed app doesn't
>>>>> seem unreasonable.
>>>>>
>>>>> [1] https://github.com/lincolnloop/django-webserver
>>>>>
>>>>> On Tue, Aug 23, 2022 at 10:14 AM Carlton Gibson
>>>>>  wrote:
>>>>> >
>>>>> > Hey Pete.
>>>>> >
>>>>> > Yes... this is a good one.
>>>>> >
>>>>> > It's difficult to see how we can even have an ASGI runserver in
>>>>> core, simply because there's no SimpleServer equivalent as there is for
>>>>> WSGI, and it's not clear one is on the card. (HTTP is getting **more**
>>>>> complex, and I can't see  Python bringing such into the standard library.)
>>>>> > So we have to use a third-party dependency for that.
>>>>> >
>>>>> > For the Channels v4 update (in progress now) I'm moving the
>>>>> runserver command to the Daphne package. This was because folks wanted to
>>>>> use Channels without the Daphne/Twisted dependency.
>>>>> >
>>>>> > See: https://github.com/django/daphne/pull/429
>>>>> >
>>>>> > tl;dr — it came out pretty clean TBH. You pip install daphne, then
>>>>> add "daphne" at the top of INSTALLED_APPS. (There's a system check to make
>>>>> sure you're not fighting staticfiles.)
>>>>> >
>>>>> > On the back of that I don't see why servers (any servers) can't
>>>>

Re: #21978 include production-ready web server

[Peter Baumgartner]

On Sat, Oct 29, 2022 at 10:06 AM Peter Baumgartner 
wrote:

> Thanks for the thorough review Florian! Some comments inline...
>
> On Wed, Oct 26, 2022 at 1:30 AM Florian Apolloner 
> wrote:
>
>> Hi Pete,
>>
>> this does look interesting. And I agree that this is something that would
>> be nice to have in core in one form or another. That said I think we have
>> to do it iteratively (ie in smaller parts) and evaluate along the way.
>>
>
> Agreed. I think adding the additional settings with some sort of
> production switch is the least obtrusive place to start.
>
>
>>
>> Since you asked for feedback, I'll tell you what I'd do differently (and
>> this is also a sign that production environment vary widely).
>>
>
> Production environments do vary widely, but I don't think that should stop
> us from providing defaults that are one-size-fits-most. startproject
> already does this and users are welcome to adjust it how they see fit.
>
>
>>
>>  * As soon as health checks check something aside from simply returning a
>> 200 status code I'd want to be able to limit access to them
>>
>
> Yep, that seems reasonable. Although depending on the level of failure,
> you may not be able to log in to see them. Starting with just a view that
> responds with a 200 is reasonable.
>
>
>>  * I like my dev env to be as close as possible to production so I
>> usually also use whitenoise in dev. I had to many times where dev worked
>> and whitenoise in prod failed then :D
>>
>
> Also a good point... I'll add that.
>
>
>>  * I do hate `DJANGO_ENV` but I guess there is no way around it.
>> Currently my projects often piggy-back on DEBUG but that can be rather hard
>> from time to time
>>
>
> I'm open to other suggestions here, but am kind of in the same boat. There
> may be times when you briefly want DEBUG=True in a non-public deployed
> environment or DEBUG=False in a development environment. Overloading that
> makes those scenarios a challenge.
>
>
>>  * I prefer settings in settings files (ini/yaml/toml) as opposed to env
>> variables that leak down the whole process-tree. django-environ does
>> support this; that said there are other options like dynaconf which also
>> support hashicorp vault which is a massive plus imo. Just being able to
>> utilize vault for free from every django application out there would be
>> stellar.
>>
>
> I'm 100% in agreement here. I wrote goodconf [1] for this before I knew
> about dynaconf which does a lot of the same things. I would love to see
> Django adopt a split between "settings" (which I see as things that don't
> change across environments) and "configuration" (things that you set per
> environment). I did switch to django-environ's FileAwareEnv [2] which
> allows loading from files, but not in the yaml./toml sense. I didn't go all
> in here because I felt like it was a more controversial stance and at the
> end of the day, you probably still need to support environment variables
> because many (most?) PaaS providers don't have support for files like that.
>
> With the goal of getting something merged into Django eventually, I felt
> like environment variables were the lowest bar. We have precedence for
> loading from environment variables with DJANGO_SETTINGS_MODULE. Do you
> think a more full-featured library like dynaconf would make it harder to
> push some of this upstream? Users that want to use dynaconf or goodconf or
> whatever can still edit their settings and use those like they do today.
>
> [1] https://github.com/lincolnloop/goodconf
> [2]
> https://django-environ.readthedocs.io/en/latest/tips.html#docker-style-file-based-variables
>

Had another thought here... what about providing a pluggable configuration
backend? Django could ship with some native backends like environment
variables and toml (when it's available). Third party packages could
provide Vault, secret files, etc. Same as how storages currently works and
how you can easily drop in something like django-storages.


>
>
>>
>> Another thing about settings, and this is something I really like in
>> spring-boot is their relaxed binding for configuration variables. You can
>> look at
>> https://github.com/spring-projects/spring-boot/wiki/Relaxed-Binding-2.0
>> for an example. They describe there how hierarchical variables are handled
>> and translated between yaml and env variables. Of course this binding is
>> not exactly bidirectional always (I think) but it allows for a few nice
>> things. First off you can start with a config file in yaml (one m

Re: #21978 include production-ready web server

[Peter Baumgartner]

Hey Tobias! Not using DJANGO_SETTINGS_MODULE is due to my personal dislike
of it :)
I don't like the idea of a totally different Python file getting imported
based on an environment variable and I feel like having different Python
files for each environment isn't a great pattern. I think it is easier to
have major deviations between environments that aren't ever tested until
that environment is reached. I don't love Python being the language for
this type of configuration. I think something static like toml/yaml (or env
vars in a pinch) is easier to reason about, easier to dynamically generate,
and ultimately needs to be used if you want to avoid hard-coding secrets in
your repo.

All that being said, I realize the difference is subtle and goes against
the grain of what's already there. I'm willing to go whatever route makes
it easiest to get accepted.

On Sat, Oct 29, 2022 at 6:02 PM 'Tobias McNulty' via Django developers
(Contributions to Django itself)  wrote:

> Hi Pete,
>
> A pluggable backend sounds like a good idea.
>
> Regarding DJANGO_ENV, why not ship the template with two settings files
> and use the existing DJANGO_SETTINGS_MODULE, instead of adding a new
> environment variable?
>
> Maybe that would be controversial too, I'm not sure, but perhaps less so
> than introducing a new paradigm? In any event, perhaps a pluggable backend
> would allow everyone to be happy, or very nearly so... 😅
>
> To be clear, I'm fully in support of this, no matter how it ends up.
> Providing a decent production-capable server and some sane
> settings/configuration defaults for people to work from -- rather than
> having to scour the documentation for every mention of a production
> environment and figure out how to make those changes by hand -- will be a
> big win IMO. As it stands, first time users might reasonably assume they
> should use Apache to deploy to production (maybe they should, I'm not
> sure...but I haven't seen it done in over a decade):
>
> "We’ve included this with Django so you can develop things rapidly,
> without having to deal with configuring a production server – such as
> Apache – until you’re ready for production."
>
> https://docs.djangoproject.com/en/4.1/intro/tutorial01/
>
> Cheers,
> Tobias
>
> On Sat, Oct 29, 2022, 7:15 PM Peter Baumgartner 
> wrote:
>
>>
>>
>> On Sat, Oct 29, 2022 at 10:06 AM Peter Baumgartner 
>> wrote:
>>
>>> Thanks for the thorough review Florian! Some comments inline...
>>>
>>> On Wed, Oct 26, 2022 at 1:30 AM Florian Apolloner 
>>> wrote:
>>>
>>>> Hi Pete,
>>>>
>>>> this does look interesting. And I agree that this is something that
>>>> would be nice to have in core in one form or another. That said I think we
>>>> have to do it iteratively (ie in smaller parts) and evaluate along the way.
>>>>
>>>
>>> Agreed. I think adding the additional settings with some sort of
>>> production switch is the least obtrusive place to start.
>>>
>>>
>>>>
>>>> Since you asked for feedback, I'll tell you what I'd do differently
>>>> (and this is also a sign that production environment vary widely).
>>>>
>>>
>>> Production environments do vary widely, but I don't think that should
>>> stop us from providing defaults that are one-size-fits-most. startproject
>>> already does this and users are welcome to adjust it how they see fit.
>>>
>>>
>>>>
>>>>  * As soon as health checks check something aside from simply returning
>>>> a 200 status code I'd want to be able to limit access to them
>>>>
>>>
>>> Yep, that seems reasonable. Although depending on the level of failure,
>>> you may not be able to log in to see them. Starting with just a view that
>>> responds with a 200 is reasonable.
>>>
>>>
>>>>  * I like my dev env to be as close as possible to production so I
>>>> usually also use whitenoise in dev. I had to many times where dev worked
>>>> and whitenoise in prod failed then :D
>>>>
>>>
>>> Also a good point... I'll add that.
>>>
>>>
>>>>  * I do hate `DJANGO_ENV` but I guess there is no way around it.
>>>> Currently my projects often piggy-back on DEBUG but that can be rather hard
>>>> from time to time
>>>>
>>>
>>> I'm open to other suggestions here, but am kind of in the same boat.
>>> There may be times when you briefly want DEBUG=Tr

Re: #21978 include production-ready web server

[Peter Baumgartner]

On Sun, Oct 30, 2022 at 7:57 AM Florian Apolloner 
wrote:

> Hi Peter,
>
> On Saturday, October 29, 2022 at 6:07:16 PM UTC+2 pe...@lincolnloop.com
> wrote:
>
>> Since you asked for feedback, I'll tell you what I'd do differently (and
>>> this is also a sign that production environment vary widely).
>>>
>>
>> Production environments do vary widely, but I don't think that should
>> stop us from providing defaults that are one-size-fits-most. startproject
>> already does this and users are welcome to adjust it how they see fit.
>>
>
> Agreed, I should have written this better. I expect there to be plenty of
> different opinions on this topic and it might be hard to figure out the
> one-size-fits-most without being to limiting.
>
>
>> * As soon as health checks check something aside from simply returning a
>>> 200 status code I'd want to be able to limit access to them
>>>
>>
>> Yep, that seems reasonable. Although depending on the level of failure,
>> you may not be able to log in to see them. Starting with just a view that
>> responds with a 200 is reasonable.
>>
>
> Sure and with limiting access I was more thinking about source IPs than
> actual logins (ie open health endpoint to the internal network from which
> the loadbalancer connects)
>
>
>>  * I do hate `DJANGO_ENV` but I guess there is no way around it.
>>> Currently my projects often piggy-back on DEBUG but that can be rather hard
>>> from time to time
>>>
>>
>> I'm open to other suggestions here, but am kind of in the same boat.
>> There may be times when you briefly want DEBUG=True in a non-public
>> deployed environment or DEBUG=False in a development environment.
>> Overloading that makes those scenarios a challenge.
>>
>
> Jupp, that is also the reason why I am in a love/hate relationship with it
> :)
>
>
>>  * I prefer settings in settings files (ini/yaml/toml) as opposed to env
>>> variables that leak down the whole process-tree. django-environ does
>>> support this; that said there are other options like dynaconf which also
>>> support hashicorp vault which is a massive plus imo. Just being able to
>>> utilize vault for free from every django application out there would be
>>> stellar.
>>>
>>
>> I'm 100% in agreement here. I wrote goodconf [1] for this before I knew
>> about dynaconf which does a lot of the same things. I would love to see
>> Django adopt a split between "settings" (which I see as things that don't
>> change across environments) and "configuration" (things that you set per
>> environment). I did switch to django-environ's FileAwareEnv [2] which
>> allows loading from files, but not in the yaml./toml sense. I didn't go all
>> in here because I felt like it was a more controversial stance and at the
>> end of the day, you probably still need to support environment variables
>> because many (most?) PaaS providers don't have support for files like that.
>>
>
> Yes, being able to override stuff via env variables should probably be
> always allowed. And as long as we do have a "schema" of some kind (be that
> via config.get_bool or typing annotation on a configuration object) it is
> also relatively easy to convert env variables to their correct form (ie
> boolean).
>
> With the goal of getting something merged into Django eventually, I felt
>> like environment variables were the lowest bar. We have precedence for
>> loading from environment variables with DJANGO_SETTINGS_MODULE. Do you
>> think a more full-featured library like dynaconf would make it harder to
>> push some of this upstream? Users that want to use dynaconf or goodconf or
>> whatever can still edit their settings and use those like they do today.
>>
>
> Yes and no. A 3rd party dependency will make it certainly harder to get
> this merged upstream. On the other hand I wouldn't want to support env
> variables only in the first iteration if that makes adding support for
> "properly" typed schemes (yaml/toml) harder in the future. From a viability
> point I'd like to see that we have an API that can handle hierarchical
> typed config and env variables. If we get that right the reasons to use
> something else will be rather small I guess.
>
> > Had another thought here... what about providing a pluggable
> configuration backend? Django could ship with some native backends like
> environment variables and toml (when it's available). Third party packages
> could provide Vault, secret files, etc. Same 

Re: #21978 include production-ready web server

[Peter Baumgartner]

On Mon, Oct 31, 2022 at 11:52 AM Florian Apolloner 
wrote:

> On Monday, October 31, 2022 at 5:27:02 PM UTC+1 pe...@lincolnloop.com
> wrote:
>
>> In my ideal scenario, the default is a hard-coded settings file for the
>> project (deprecating DJANGO_SETTINGS_MODULE env var) and we have
>> CONFIG_LOADERS defined in the settings that could do env, toml, etc.
>> Perhaps things like django.setup,
>>
> django.core.wsgi.get_wsgi_application, and
>> django.core.management.execute_from_command_line could accept the settings
>> module as an argument? django-admin could accept a --settings flag?
>>
>
> I doubt that will ever fly. There is no project so to say in Django.
> Currently literally everything depends on knowing a
> `DJANGO_SETTINGS_MODULE` from which everything else can follow (even the
> wsgi app…). So without a settings file how would you know that hard-coded
> path for it? Django has no concept of a project that you could import. You
> also cannot easily put `CONFIG_LOADERS` in a settings file like we
> currently have because then how are you going to evaluate that while also
> executing all the other module level stuff. And django-admin command all
> already support a `--settings` flag (as alternative to
> DJANGO_SETTINGS_MODULE ;))
>
> Either way I doubt we will deprecating DJANGO_SETTINGS_MODULE any time
> soon. And I don't see it such of a problem with being there. Projects can
> set it (and startproject already does this) to a fixed value in manage.py &
> wsgi.py. For a project that installs a custom entrypoint script, you can
> also preset it to whatever you like.
>
> Please note that we are trying to load stuff from files & env vars in the
> first step, not throw out settings.py at the same time…
>

I figured it wouldn't fly :)

I misunderstood your chicken-egg question above. What I've been doing is
defining a "Config" class and instantiating it in the settings file.
Instantiation of the class (or calling an explicit method on it) would do
the env/file loading and the instance becomes your `env` object. Rather
than having a CONFIG_LOADERS setting, you could define them on the Config
class or when you instantiate it. This is pretty similar to how goodconf
works today. https://github.com/lincolnloop/goodconf#quick-start


>
> Cheers,
> Florian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b0cc8e42-0781-4a69-b8a1-12cc6929c2f7n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6K9znR0RwrW%2B9SVMOy56mg%3DOuAYafBExGJf8n-TFdefhhKeA%40mail.gmail.com.

Models CRUD via web services (ticket 115)

[Peter Ferne]

Hi all,

I'm about to implement a RESTful API to some Django models and
wondering whether to try and build on any of the patches checked in
against any of the tickets marked as duplicates or subsets of #115. Or
wait? Or just code from scratch?

I can't help noticing that on 11 Oct 2005 jacob said:
> ...as I'm going to try and get some work done on this Any Day Now™

Just wondering what the progress on this is?

TIA
--
petef

Re: What if instead of calling them "projects" we called them "sites"?

[Peter Ma]

Project is a business term,  advise application

On 3/4/06, Sean Perry <[EMAIL PROTECTED]> wrote:
>
> Jeremy Dunck wrote:
> > On 3/2/06, Sean Perry <[EMAIL PROTECTED]> wrote:
> >
> >>I am definitely -2 on this. Malcolm does a good job of starting the ball
> >>rolling as to why.
> >
> >
> > The range is -1..+1  ;-)
> >
>
> with room for hyperbole (-:
>
>
>
>


--
www.mawei.name
Petit
IM&mail:[EMAIL PROTECTED]
13585201588

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

Peter Ma wants to talk to you using Google Talk

[Peter Ma]

I've been using Google Talk and thought you might like to try it out.
We can use it to call each other for free over the internet. Here's an
invitation to download Google Talk. Give it a try!

-------

Peter Ma wants to talk to you for free using Google Talk.

If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-54753eee28-c6ea90c5a5-3345ca5df4124069
You'll need to click this link in order to add Peter Ma to your
Friends list and talk with each other for free.

To try Google Talk (and get Gmail, a free Google email account with
over 2,500 megabytes of storage) visit:
http://mail.google.com/mail/a-54753eee28-c6ea90c5a5-e482d0bbc1

Google Talk is a downloadable Windows* application that lets you send
instant messages to your friends and make free phone calls over an
internet connection. Google Talk offers excellent voice quality and
works with any computer speaker and microphone.

Gmail is Google's free email service, offering lots of free storage,
powerful spam protection, built-in search for finding your messages,
and a helpful way of organizing email into "conversations." And there
are no pop-up ads or untargeted banners -- just text ads and related
information that are relevant to the content of your messages.

Once you sign up, we'll notify Peter Ma of your new Gmail address
and add you to each others' Friends lists so you can start talking right
away.

Gmail and Google Talk are still in beta. We're working hard to add new
features and make improvements, so we might also ask for your comments
and suggestions periodically. We appreciate your help in making our
products even better!

Thanks,

The Gmail and Google Talk Teams


To learn more about Gmail and Google Talk, visit:
http://mail.google.com/mail/help/benefits.html
http://www.google.com/talk/about.html

(If clicking the URLs in this message does not work, copy and paste
them into the address bar of your browser).

* Not a Windows user? No problem. You can also connect to the Google
Talk service from any platform using third-party clients
(http://www.google.com/talk/otherclients.html).

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

Re: How to stop testserver from within a test case?

[Peter Inglesby]

Hi Arun,

This group is for discussion of development of Django itself.  Your
question is better suited to the 'Django users' group:
https://groups.google.com/forum/#!forum/django-users

All the best,

Peter

On 18 November 2014 15:51, Arun Marathe  wrote:

>
>
>
> We have Django 1.6.
>
> For a somewhat obscure reason, I need to stop the testserver from within a
> test case. Any ideas?
> I would like a programmatic solution if possible. Finding a process and
> killing it (ps -ef., then grep,
> then kill) is bit of a hack, and may end up killing unintended processes.
>
> Note that I want the testserver stopped for a small number of test cases.
> For the rest of them, the
> testserver should be running as it always does.
>
> Thanks,
> Arun
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/422b87d4-f4c2-468b-a4ad-1219f61b96e5%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/422b87d4-f4c2-468b-a4ad-1219f61b96e5%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAENJrP%3DQ324Z-jHeUH3bdQM1uG2BmOsiPkL%2BhiFiVONV0zd1Jw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

default current_app

[Peter Lauri]

This thread was started in django-users, but commented that it should be 
moved to developers list instead.

Take a look at the original thread 
here: https://groups.google.com/forum/#!topic/django-users/F0J6fKP1un8

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2b39376d-4e1a-44c2-b6d8-c872be7dd913%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django Admin - ModelAdmin exclude

[Peter Farrell]

We are writing a custom admin for CleanerVersion that subclasses ModelAdmin. 
Just about every attribute has a hook method which makes extension easier. For 
example, list_display has get_list_display(). However, exclude doesn't have one 
implemented and it seems like an oversight. I'm proposing we add one.

Our current work seeking is to write a property descriptor for exclude but then 
the admin check fails with it not being a tuple or list. Then you have to 
create a custom admin checks class to suppress the exclude check error because 
it's not a tuple or list (but really a descriptor).

If this is ok, I'Ill write a PR.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c1e8762d-1c9f-47e9-8fe7-e9761c27e057%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin - ModelAdmin exclude

[Peter Farrell]

I agree there are many ways to accomplishing things in the admin, but 
cleaning that up and continuing BC is a completely other ticket / 
implementation (it looks like a good Sumer of Code project similar to the 
Meta API recently completed).  Since the ticket was marked as accepted, 
I'll double check my patch and make a PR this week.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a7d259f5-e54f-4511-825c-93e8f4cd3de8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 8040 SlugField format not enforced - fixed, closed an "ready for checkin" since two years

[Peter Baumgartner]

It just moved. See:

http://code.djangoproject.com/browser/django/trunk/django/forms/fields.py#L924
http://code.djangoproject.com/browser/django/trunk/django/core/validators.py#L122

-- Pete

On Tue, Oct 12, 2010 at 8:44 AM, Sebastian  wrote:
> Hello,
> I investigated a bit further, it was commited with r8477
> http://code.djangoproject.com/changeset/8477
>
> But somewhere it got lost. In the current definition for SlugField I
> can only find a validation for max_length:
> http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/__init__.py#L1000
>
> Sebastian
>
> On 12 Okt., 13:34, Luke Plant  wrote:
>> On Tue, 2010-10-12 at 04:21 -0700, Sebastian wrote:
>> > Hello,
>> > the ticket "SlugField format not enforced" is fixed, closed an "ready
>> > for checkin" since two years. What can I do?
>>
>> It is 'closed: fixed', which means the fix entered to the code base -
>> two years ago, as you say.  There is nothing left to do, so I don't see
>> what the problem is.
>>
>> Luke
>>
>> --
>> "He knows the way I take: when he has tried me, I shall come forth
>> as gold" (Job 23:10).
>>
>> Luke Plant ||http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: contrib.staticfiles app concerns

[Peter Landry]

On 10/21/10 11:10 AM, "Jacob Kaplan-Moss"  wrote:

> On Thu, Oct 21, 2010 at 3:50 AM, Waldemar Kornewald
>  wrote:
>> With this reasoning we could as well add django-debug-toolbar, South,
>> django-registration and many other popular apps. What makes
>> staticfiles different? Seriously, I don't see it.
> 
> Jannis proposed that we add static files in. Brian concurred. So did
> I. No core developers objected.
> 
> You're completely right about DDT, South, and -registration. What
> makes them different?
> 
> * Nobody's asked that DDT be included in Django. Last I spoke to Rob
> about it, he felt it needed a bit more time as a third-party app to
> stabilize the API and get more robust. I'd happily support moving DDT
> into contrib if there's sufficient interest.
> 
> * We've (at least, Russ and I have) talked a lot with Andrew about how
> South might fit into contrib. The consensus was that there's still a
> good deal of exploring to be done in the schema evolution space --
> there's at least a couple-three tools that could easily be considered
> "good enough". However, we agreed that we should push some of the
> parts of schema migration down into Django,  particularly DDL
> generation, migration discovery, and perhaps migration tracking.
> Andrew was offered a commit bit partially to help make this work
> happen more smoothly.
> 
> * Like DDT, nobody's proposed that -registration be included in
> Django. I'm not sure that James would be interested, either: he's got
> a different opinion on contrib versus external apps than I do. Like
> DDT, I'd go along if there was sufficient interest and if James was
> willing.
> 
> Jacob

I think South is the best candidate here, because it could improve the third
party app ecosystem to have a stable and consistent migration framework
battery included. DDT and django-registration both stand alone pretty well,
so I see less benefit (though I don't have any particular objections,
either).

Under that rubric, I agree that staticfiles is a good candidate, as well.

Peter


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

No default comment_notification_email.txt, no docs

[Peter Herndon]

Hi all,

I just ran into a minor issue and thought I'd bring it to light.  In adding 
django.contrib.comments to a site I'm building, I found that when using 
moderation and setting email_notification to True, that there is no default 
template for comment_notification_email.txt included with the other comments 
templates.  There is also no documentation I could find that mentions what 
context is provided to the template.  I found it easily enough by reading the 
email method of the CommentModerator class in 
django/contrib/comments/moderation.py, but that seems less than optimal.

I'm happy to open a ticket, but should the solution be to include a default 
template, to add relevant documentation pointing out the customization 
possibility, or both?

Regards (and many thanks for an incredible framework!),

---Peter Herndon

-- 
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: No default comment_notification_email.txt, no docs

[Peter Herndon]

On Nov 8, 2010, at 9:14 AM, Carl Meyer wrote:

> Hi Peter,
> 
> On Nov 7, 9:41 pm, Peter Herndon  wrote:
>> I just ran into a minor issue and thought I'd bring it to light.  In adding 
>> django.contrib.comments to a site I'm building, I found that when using 
>> moderation and setting email_notification to True, that there is no default 
>> template for comment_notification_email.txt included with the other comments 
>> templates.  There is also no documentation I could find that mentions what 
>> context is provided to the template.  I found it easily enough by reading 
>> the email method of the CommentModerator class in 
>> django/contrib/comments/moderation.py, but that seems less than optimal.
>> 
>> I'm happy to open a ticket, but should the solution be to include a default 
>> template, to add relevant documentation pointing out the customization 
>> possibility, or both?
> 
> In general, contrib.comments includes defaults for all the templates
> it needs, which suggests this one ought to be included too. On the
> other hand, contrib.auth doesn't include default templates for the
> email it sends for password-reset. Hmm. My inclination is to say that
> a simple default template for that email should be included, and the
> docs should include mention of the template and the context it
> receives.
> 
> Carl
> 

Hi Carl,

I filed ticket 14646, with a patch including a default template and some 
additional documentation.

---Peter

-- 
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: Ticket #7817: Extending "with" and "include" tags.

[Peter Baumgartner]

On Thu, Nov 4, 2010 at 5:37 AM, silent1mezzo  wrote:
> +1 for {% include "foo.html" x=1 y=2 %}
>
> This just seems more natural.  My designer agreed based on the {% url
> %} tags.
>

+1 for using the = syntax here. My reasons have been mentioned above,
but to recap:

* and/as gets too verbose and difficult to read if you add more than a
couple variables
* HTML uses "=" to set attributes, so this shouldn't be a new paradigm
for template authors

-- Pete

-- 
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: Pluggable encryption for django auth (design proposal)

[Peter Landry]

I'm not an expert, but that's correct. A too-fast or broken hash function
will still be "vulnerable" to a brute force attack [1]. Salting doesn't
prevent this.

Peter

[1] 
http://stacksmashing.net/2010/11/15/cracking-in-the-cloud-amazons-new-ec2-gp
u-instances/

On 2/11/11 9:57 AM, "william ratcliff"  wrote:

> Hi!  The scenario that I am considering is when the attacker has your
> database--can they compromise the passwords in it?  While I believe that a
> salt will protect you against a "Rainbow Table" attack, I'm not convinced that
> it will protect you against the brute-force attacks which are now possible.  I
> will try to consult some experts today and see if they are willing to go on
> record.
> 
> William
> 
> On Fri, Feb 11, 2011 at 8:10 AM, Eduardo Cereto Carvalho
>  wrote:
>> I'm not an expert on the subject.
>> 
>> But I think that the hashes security issues are olved by the use of a "salt",
>> salted hashes are known to be a very secure way to store data.
>> 
>> 
>> 
>> On Fri, Feb 11, 2011 at 3:59 AM, William Ratcliff
>>  wrote:
>>> Hi!  I'm new to the list and have started to look into authentication.   I
>>> find that I will need to patch it for my own needs, but would like to ask
>>> the opinions of others who are more familiar with the code-base than I am.
>>> I apologize if I make any mistakes in the protocol of the list in matters
>>> such as including too much code.
>>> 
>>> SHA1 is not secure.  This is not a nationalism issue.  For example:
>>> http://www.darknet.org.uk/2010/11/sha-1-password-hashes-cracked-using-amazon
>>> -ec2-gpu-cloud/
>>> 
>>> Or, from NIST:
>>> http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html
>>> 
>>> where the relevant excerpt is:
>>> March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224, SHA-256,
>>> SHA-384 and SHA-512) may be used by Federal agencies for all applications
>>> using secure hash algorithms. Federal agencies should stop using SHA-1 for
>>> digital signatures, digital time stamping and other applications that
>>> require collision resistance as soon as practical, and must use the SHA-2
>>> family of hash functions for these applications after 2010. After 2010,
>>> Federal agencies may use SHA-1 only for the following applications:
>>> hash-based message authentication codes (HMACs); key derivation functions
>>> (KDFs); and random number generators (RNGs). Regardless of use, NIST
>>> encourages application and protocol designers to use the SHA-2 family of
>>> hash functions for all new applications and protocols.
>>> 
>>> I have also seen discussions in other venues from people who are worried
>>> about the security of SHA1 in the event that their system is compromised,
>>> can an attacker gain the passwords in the database?  The appearance of
>>> modules such as django-bcrypt:
>>> https://github.com/dwaiter/django-bcrypt/
>>> show that this issue is becoming of more general concern.
>>> 
>>> Current solutions:
>>> 1)  Monkey patch:
>>> put a top level installed_app that has a listener to the class_prepared
>>> signal that performs monkey patching throughout user.
>>> This is rather ugly and it feels very fragile to me if the auth module
>>> changes internally.
>>> 2)  Rewrite the Backend as Tom suggests by subclassing ModelBackend:
>>> Again, it's not sufficient.  Why?
>>> 
>>> If we look at the Model Backend, we see that yes, the authenticate method
>>> currently authenticates against User--but the problem is NOT the
>>> authentication per se, but rather that the User class has several methods
>>> such as:
>>> check_password, set_password, etc. that have encryption hard coded.   There
>>> are admin commands associated with the User class which refer to methods
>>> with a particular encryption method chosen.
>>> 
>>> 3) For users of Django who cannot (say US government agencies, people who
>>> have tight security concerns, etc.) use the current module, ignore the auth
>>> module and roll their own:
>>> This has been attempted before.  However, the problem is that it is easy to
>>> make mistakes doing this and most of the functionality in the auth module is
>>> very good and simply copying most of it to make a few changes to User--and
>>> to maintain those against modules which use the user module seems rather
>>> excessive.
>>> 
>>>

Is there a particular reason why the condition decorator does not use wraps?

[Peter Portante]

Looking at line 153 of django/views/decorators/http.py (rev [15927]),
I just see "return inner". Is there a particular reason why it should
not be: "return wraps(func, assigned=available_attrs(func))(inner)"?

-- 
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: Fixing makemessages for Javascript

[Peter Portante]

+1 from the Tabblo group remnants.

On Thu, Apr 14, 2011 at 8:41 AM, Ned Batchelder wrote:

> Does anyone else have any opinions on a direction forward to fix this
> problem?  At the very least I'd like to make a doc patch for 1.3.1 that
> explains the fragility.
>
>

-- 
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: Is there a particular reason why the condition decorator does not use wraps?

[Peter Portante]

See ticket 15840.

On Thu, Apr 14, 2011 at 9:25 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Thu, Apr 14, 2011 at 8:16 PM, Peter Portante
>  wrote:
> > Looking at line 153 of django/views/decorators/http.py (rev [15927]),
> > I just see "return inner". Is there a particular reason why it should
> > not be: "return wraps(func, assigned=available_attrs(func))(inner)"?
>
> I suspect it's just historical oversight; I can't think of an obvious
> reason that it shouldn't be wrapped. Open a ticket with a patch (and
> run the tests to make sure nothing explodes unexpectedly), and we can
> get that fixed.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

django.db.models.loading suppresses an ImportError leading to None value weirdness

[Peter Russell]

Hi

I've encountered a problem with Django 1.3 when app loading. It has
taken a while to get to the root cause because I am working on a
large
application and because the errors were so bizarre.

Basically, It's possible for all apps to successfully import, but when
you execute any methods on your models you get errors because all
global variables are assigned to None.

Here is some detail about how and why the problem occurs and a few
ideas for fixing it.

Any feedback or advice before I submit a patch would be appreciated.

_The short version_

The metaclass of Model caches model classes and reuses them if it sees
them being redefined. At the same time the _populate method of
AppCache
can ignore ImportError and retry importing a models module.

This means that the model classes you see in a models module may have
been created before the current version of the module object. When the
models have methods (or in my case a custom manager, which has
methods),
the methods store a reference to the namespace they were defined in
(im_globals), and since the old module object has gone out of scope,
all
of the values in that namespace are set to None.

This means that although my code seems to have imported correctly,
when
I try to run anything I get all sorts of weird errors. I'm pretty sure
this is a bug.

_My scenario_

I'm working on a project where all of the model definitions were
originally put in a models.py. We're now trying to break this up into
more sensible apps. I've moved some classes into a new app, but for
now
there is a cyclic dependency between the two.

I've done all the things you do when you have a mess of complex
dependencies, moving imports to the top and bottom of the files,
shuffling them, passing ForeignKey strings instead of classes, and
reordering INSTALLED_APPS, and I'd finally got it to the point where I
was no longer getting an ImportError when I tried to run my tests.
However the tests were all failing, because our custom Managers were
failing. The error looked something like:

query_set = super(CustomManager, self).get_query_set()
TypeError: must be type, not None

It seems CustomManager was bound to None!

_Possible Fixes_

1. Don't reuse cached model definitions. Instead allow creation to
go ahead as normal and replace the version in the cache. I'm
not sure if this is supposed to be an optimisation, or if there
would be deeper problems in doing this.

2. Don't try to reimport modules after a failure. This would be my
preferred option because it makes it clear that to the
programmer what they have to do to fix the problem. In my case
my code has a bug, it doesn't import. If I fix the ImportError
then I won't have this problem. I suppose this will probably
break someone's code though :-(

3. Make the cache of model definitions behave transactionally.
When importing an app raises ImportError, remove all of the
models which have been inserted since we started before moving
on to the next one.

Thanks

Peter Russell

-- 
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: Fixing makemessages for Javascript

[Peter Portante]

FWIW: we are successfully using Ned's fix on top of 1.2.5 today. -peter

-- 
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: Should postgresql cascade after truncate

[Peter Russell]

I have a different problem, but the solution to both might be the same.

We use a lot of ForeignKeyFields with on_delete=models.DO_NOTHING,
since we found the default cascade behaviour dangerous (it was too
easy for one ill thought through delete to take out half the
database).

I've just been writing a test which checks that a delete() method
works correctly.  The test passes, but on closer inspection it should
have failed, because creating my object creates a second object which
is not being deleted.  In principle Postgres will raise an
IntegrityError about this, but because all foreign keys are created
"DEFERRABLE INITIALLY DEFERRED", the check doesn't happen until the
transaction is committed... which doesn't happen.  If I switch to
using TransactionTestCase (which is massively slower), the test fails
as expected.

I haven't tested this yet, but I suspect that if I modified the Django
TestCase code to emit "SET CONSTRAINTS ALL IMMEDIATE;" before it
truncates the tables my IntegrityError will be raised.

I think it should also tell you about your dangling foreign keys.  It
would be down to you to remove them, but it avoids having to have
Django mess with unmanaged tables.

I'll have a play and see how hard it would be.

Thanks

Peter Russell

-- 
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: Should postgresql cascade after truncate

[Peter Russell]

On Tue, Jun 21, 2011 at 8:43 PM, Ramiro Morales  wrote:
> That's what [1]ticket 11665 reports.

So it does!  I'd just hit the problem when I wrote my mail, and hadn't
checked Trac yet.

I guess I'll apply the patch and see if it solves my problem tomorrow.

Thanks

Peter

-- 
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: [RFC] Improvements to better support implementing optimistic concurrency control

[Peter Portante]

Essentially, you want a compare-and--swap instruction for a database?

Have you considered using memcached atomicity (add and cas) to handle this
kind of thing? It might get pretty elaborate, but with just a cursory
thought seems doable.

-peter

On Sat, Aug 6, 2011 at 9:59 PM, Steven Cummings wrote:

> Bad community member that I am, I jumped the gun and logged a ticket
> [1] on this one... anyway:
>
> Websites general avoid overly aggressive locking of data to deal with
> concurrency issues. When two users allowed to edit some data are
> simultaneously doing so, they're both allowed to do so and the
> last .save() wins (race condition). This is largely acceptable on the
> web as when two people are allowed to edit data they shouldn't be
> prevented to doing so. Further sites often have audit history (whether
> or not exposed to those users owning/managing the data) which tracks
> exactly what went on.
>
> However, some sites may wish to detect this situation and present the
> 2nd user with a page or the previous form stating that what they
> edited is now obsolete. Examples of situations where we don't want
> edits to be silently stomped are health and financial data. Bugzilla
> mid-air collisions are an example of an implementation in the wild.
>
> So, we could try to detect this by always re-querying the object just
> before update (or delete), but with sufficient traffic there is still
> the chance that two requests *think* they know the current state of it
> in storage. This is where knowing rows modified, and/or having a
> precondition check would help. I've outlined the details on the
> ticket, but generally:
>
> * To ensure the object I'm saving is not stale, I might like to do
> Model.save_if(version=version), where I have an incremented version-
> field and save_if would compare the stored value (using something like
> an F('version')) against the given value. If the version was
> different, it should raise something like PreconditionFailed.
> * For delete()s, it might be nice to get rows-modified to know that
> the current request really did perform the delete. This is important
> in cases like using an OAuth auth code, where allowing multiple uses
> (deletes) of it would be a security problem.
>
> For both these cases, it would also be useful to either get rows-
> modified (or precondition-met) in the post-save/delete signal, or to
> somehow avoid those signals firing when no data was updated.
>
> I'm fully willing to hack on this and provide patches and/or use an
> experimental branch, just wanted to get some thoughts on it.
>
> [1] https://code.djangoproject.com/ticket/16549
>
> --
> 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.
>
>

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

[Peter Melvyn]

On 6/9/08, James Bennett <[EMAIL PROTECTED]> wrote:

>  So please, in all honesty, tell me why you think Django's development
>  process isn't "visible" enough for people who are concerned and want
>  to get information.

I give you example: few weeks ago I discovered that problem  #3030
still persists: somebody fixed it by introducing
DatabaseFeatures.autoindexes_primary_keys, but left its value in the
backend.mysql.base to be False, hence the fix has no effect...

If I was asking why, there is no answer, so I don't know what
development process is behind, whether:

- everybody just fucks me off
- nobody cares about MySQL
- nobody knows
- it is an intention
- it is easiness
- will anobody fix it
- should I fix it
- etc...

###

And there is more examples...

###

Concerning the original topic: asking for frequent releases, it is
IMHO similiar as with those 'checkbox features' mentioned by Joel
Spolsky http://www.joelonsoftware.com/articles/fog000339.html

Peter

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

Re: Django releases

[Peter Melvyn]

On 6/10/08, Eric <[EMAIL PROTECTED]> wrote:

>  I'm not certain that this route is perfect, but it seems to be a
>  compromise of both worlds.


We use the same approach with mean time redundancy about 1 months.

Peter

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

MySQL and DatabaseFeatures.autoindexes_primary_keys (was: Django releases)

[Peter Melvyn]

On 6/9/08, Ian Kelly <[EMAIL PROTECTED]> wrote:

>  I don't know why this is so mysterious.  A small amount of browsing
>  turns up that the code was added in revision [4916] and specifically
>  enabled for Oracle only to fix ticket #3743.

But it does not explain why ticket #3030 has been closed (if #3743 has
fixed *only* Oracle)...


> MySQL  is an especially complicated case due to the large
> differences between  multiple supported versions.

Unfortunately yes. Being more rigorous, MySQL should require another
feature autoindexes_foreign_keys to generate foreign key constraints
correctly...

###

To treat such/similiar problems we need to distinct different MySQL
versions. As for sqlite3 we could introduce new kinds of
DATABASE_ENGINE :

mysql5
mysql5pp (5 and later)
mysql6

and modify backend properly - it should be straightforward except
cases where DATABASE_ENGINE is used directly as part of package/module
name.
(we probably should not create separated mysql5 etc...  packages)

Peter

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

Re: Bug in mod_python

[Peter Melvyn]

> I though that might be the case, I won't bother to raise a ticket then.

We had a similiar problem and discussed it on Apache forum: perhaps it
could enlighten a problem:
http://mail-archives.apache.org/mod_mbox/httpd-users/200708.mbox/[EMAIL 
PROTECTED]

HTH, Peter

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

Re: Bug in mod_python

[Peter Melvyn]

On 6/17/08, Graham Dumpleton <[EMAIL PROTECTED]> wrote:

>  Link comes out broken by Google Groups web interface.

I see - is there a way how to pass such URL via Google interface?

>  Anyway, in the mod_python case it comes down to Location directive
>  being used. The SCRIPT_NAME/PATH_INFO variables effectively need a
>  physical file resources with directory defined by Directory directive
>  and mapped by appropriate Alias directive or similar.

Yes. We were told that "correct" value for non-file resources is not
defined and we should use REQUEST_URI instead of PATH_INFO

Peter

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

Re: Errors in django/tests/regressiontests/views/fixtures/testdata.json?

[Peter Melvyn]

On 6/19/08, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:

>  (2) provide a way to manually disable and re-enable integrity checks. If
>  someone with more MySQL-fu than me knows how to do either of these

It should work:

SET FOREIGN_KEY_CHECKS = 0;

... imported data ...

mysql> SET FOREIGN_KEY_CHECKS = 1;

###

Cite: This allows you to import the tables in any order if the dump
file contains tables that are not correctly ordered for foreign keys.
It also speeds up the import operation. Setting FOREIGN_KEY_CHECKS to
0 can also be useful for ignoring foreign key constraints during LOAD
DATA and ALTER TABLE operations. However, even if
FOREIGN_KEY_CHECKS=0, InnoDB does not allow the creation of a foreign
key constraint where a column references a non-matching column type.

Peter

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

Re: Errors in django/tests/regressiontests/views/fixtures/testdata.json?

[Peter Melvyn]

On 6/19/08, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:

>  However, I was under the impression that this has the effect of
>  disabling, not just deferring key checks - that is, if you disable
>  checks, load bad data, then re-enable checks, no errors will be
>  raised. We don't want to be responsible for breaking the referential
>  integrity of a database, so this isn't a viable solution.

Yes, you are right. Cite:

Deviation from SQL standards: Like MySQL in general, in an SQL
statement that inserts, deletes, or updates many rows, InnoDB checks
UNIQUE and FOREIGN KEY constraints row-by-row. According to the SQL
standard, the default behavior should be deferred checking. That is,
constraints are only checked after the entire SQL statement has been
processed. Until InnoDB implements deferred constraint checking, some
things will be impossible, such as deleting a record that refers to
itself via a foreign key.

Peter

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

Re: How do I alter the behavior of django.db.models.Options.contribute_to_class when testing

[Peter Magnusson]

Quite understandable. I'll drop it for the moment as I have what I
need to get my project going but as Arnold said- I'll be back..

2008/8/22, Russell Keith-Magee <[EMAIL PROTECTED]>:
>
> On Fri, Aug 22, 2008 at 12:39 AM, crippledcanary
> <[EMAIL PROTECTED]> wrote:
>>
>> I am working on http://code.djangoproject.com/ticket/6148.
>> This includes a new option "db_schema" that's been added to a models
>> meta class.
>> It involves using a custom schema for any model that has this
>> attribute set.
>> The problem comes when testing.
>> In postgres a test database is created and inside that one this or
>> these new schemas are created. Works fine when creating and dropping
>> the test database.
>> In mysql schemas are treated as ordinary databases. So a test database
>> gets created. I can even create the "databases" that correspond to
>> db_schema but these will be the same as when running "live". Not
>> created INSIDE the test database but in parallel to the test database
>> and with the same name as when running normally.
>>
>> What I want to do is to alter/patch the value in db_schema with
>> something when create_test_db is used but not else.
>> This db_schema attribute has to be set at the time contribute_to_class
>> method of django.db.models.Options is called or before because it is
>> used there.
>>
>> Any hints or ideas are most welcome...
>
> My hint would be wait. We are currently in the crunch right before our
> v1.0 release. Developer attention is currently focussed on  fixing
> existing bugs and getting v1.0 out the door; I can't speak for the
> other developers, but at the moment, I simply don't have the spare
> cycles to dedicate to guiding a new feature.
>
> This doesn't mean the feature isn't worthwhile - it just means we have
> slightly different priorities at the moment. If you wait about a month
> (2 weeks to the release, and a few extra weeks to let us recover from
> the hangover), you'll get a lot more attention for your design issues.
>
> Yours,
> Russ Magee %-)
>
> >
>


-- 
Peter Magnusson
[EMAIL PROTECTED] | http://crippledcanary.se

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

Proposal: Include path and query parameters in view cache behaviour

[Peter Krantz]

Hi!

Currently query parameters are ignored when using the cache decorator
for views (only the path segment [3] is used to determine the key).
This impacts performance for Django sites where query parameters are
used for filtering and sorting of lists of items (a common use case).

I found an old discussion on this list [1] where Adrian Holovaty asked:

"The remaining question is: What's the behavior if vary_on_get() isn't
specified for a particular view? Do we cache everything (including
separate cache entries for any combination of different GET
parameters) or cache nothing (current behavior)?"

In ticket #4992 [2] I have proposed the following:

URL:s should be treated as opaque by the caching system. Consider
these sample URL:s

Request A: example.com/list/
Request B: example.com/list/?a=1&b=2
Request C: example.com/list/?b=2&a=1

If URL:s are treated as opaque, requesting A, B and C would create
three separate items in the cache. This would be the default behaviour
for the following:

@cache_page(60 * 15)
def list(request):
...

More fine grained cache behaviour could be specified with a
vary_by_param decorator like this:

@cache_page(60 * 15)
@vary_by_param("a", "b")
def list(request):
...

Requesting B and C above would create one item in the cache, i.e.
ordering is not important.

An idea would be to exclude the fragment part [3] from impacting the
cache as it is unlikely that developers rely on that for server side
behaviour (it is more likely used to give focus to a particular item
in the rendered HTML).

Kind regards,

Peter Krantz

[1]: http://groups.google.com/group/django-developers/msg/54d5750440d4bc93
[2]: http://code.djangoproject.com/ticket/4992#comment:9
[3]: http://labs.apache.org/webarch/uri/rfc/rfc3986.html#components

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

Re: How do you handle cascading deletes in your production apps?

[Peter Sagerson]

On Dec 13, 2008, at 12:13 PM, Luke Plant wrote:

>
> On Friday 12 December 2008 01:06:18 Simon Litchfield wrote:
>> +1. Definitely need some kind of cascade=False option somewhere.
>> I'd argue it should be the default.
>
> -1 on it being default.  Just because a foreign key may be nullable
> does not mean "you may safely null this data out".  Imagine, for
> instance, a table of employees, with a self referencing 'manager'
> foreign key, where directors are at the top of the tree and have
> manager=null.  Deleting any manager in such a system would turn all
> his workers into directors.  The current admin, which reflects the
> default delete behaviour, forces the issue, and that's good.
> Obviously people have different needs but we should err on the side
> of data-integrity.

It sounds like there are actually two (related) features under  
consideration: declaring a relationship to be non-cascading and  
declaring a delete operation to be non-cascading. The first one sounds  
more useful (indeed pressing) to me, but both may be reasonable  
features.

A couple weeks ago, I posted a small snippet[1] to work around this  
problem under many circumstances. This has the virtue of being very  
little code and not relying on particularly obscure Django internals.  
It does assume that every foreign key with null=True should be  
cleared. No doubt this will not work with every model, but I had no  
problem enforcing this rule in my own app. It probably won't win any  
awards for efficiency, but delete operations are pretty rare in my  
case, so I optimized for clarity and simplicity.

If I had been unable to work around this, I think it would have been a  
deal-breaker for me.

[1] http://www.djangosnippets.org/snippets/1231/


--~--~-~--~~~---~--~~
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: [GSOC-Testing] Kubasik Status Update

[Peter Herndon]

Yes!  Even if I don't make it to Djangocon, I'd still love to see the  
info available.

---Peter Herndon
http://spookypony.com

On Jul 12, 2009, at 3:34 AM, Kevin Kubasik wrote:

> So I was traveling some this week and getting back into the swing of  
> things back here in Utah. I didn't get to the twill backend I wanted  
> to write this week, but I did start to write real documentation.
>
> The other thing I wanted to measure responses on is submitting a  
> talk on windmill integration at djangocon. Would there be interest?
>
> -- 
> Kevin Kubasik
> http://kubasik.net/blog
>
> >


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

Model inheritance problem, inherited instances

[Peter Cicman]

Hi, first of all, this question maybe don't belongs here, i konw, but
anyway i didn't found noting about it in docs, and also in the source,
and 2 hours spend on it sisn't bring anything. So i had decided to ask
here

explanation, i have:

class A(models.Model):
name = models.CharFiled(, required=True)
.
class B(A):


I have an existing instance of A, say `a` and i "want to make"
instance of b out of it.

i'm looking for something like:
b = B()
b.origin = a
b.save()

Is this somehow possible? Forcing a foreign key doesn't work - because
of the validation of required field in model A.

Thanks a lot!

--~--~-~--~~~---~--~~
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 request: admin notifications

[Peter Herndon]

On 07/29/2009 05:05 AM, Daniel Pope wrote:
> My suggestion is a system for administrators to be notified about
> specific model instances about which they need to take action. At
> present administrators have to identify where to make changes by
> browsing the site. Some example use cases:
>
> 1. Comments - a list of new comments requiring moderation.
> 2. Stock level low - a list of SKUs with fewer than say, 5 items left in 
> stock.
> 3. Draft articles - a list of unpublished articles, for the
> convenience of administrators.
> 4. Data inconsistencies - while model validation should do for any
> really functional inconsistencies, I often come across situations
> where I want to warn admins rather than outright forbid the model to
> be saved. Case in point: I want to warn if the number of products in a
> category would require me to paginate them onto 2 pages as this is
> undesirable for usability.
>
> I would propose a way to register notification querysets in the admin.
> If a non-zero number of results present, a message appears in the
> admin, including the number of items to administer, and a link to a
> changelist that displays only matching models. I'd ideally like to
> select an icon too, so that I can differentiate between alerts,
> warnings and mere information.
>
> Dan
>

Hi Dan,

One fairly simple way to do this would be to set up a Notification model 
to hold these kinds of notifications, build a nice admin.py and some 
admin templates for it, and then build post_save signal handlers for 
each (Stock, Comments, etc.) that create new Notifications when 
appropriate.  You can add in email, SMS, and/or Twitter alerts in the 
signal handlers in order to get push notifications.

This seems like a straight-forward approach, but it isn't particularly 
generic.  You'd need to code custom logic for each of your post_save 
signal handlers -- if any new comment is posted, then notify; if stock 
is reduced and total amount of stock is < 5, then notify; if # of 
products in a category > 10, then notify.

Hmm.  One could code up a base signal handler, and a library of signal 
handler subclasses that handle configurable logic variations.  
Similarly, one could create a base notify action, and a library of 
notification subclasses to implement various features.  And perhaps some 
means of chaining them -- base Notify creates a Notification, then do an 
Email notification, then do a Twitter notification.

I'd say, though, such a framework should start life as a third-party 
reusable app.  Neat idea, this would be something I would likely use.

---Peter

--~--~-~--~~~---~--~~
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: Supported Python versions for Django 1.7

[Peter Herndon]

Hi all,

For those on RHEL6 or a derivative, please note that RHEL Software Collections 
will provide an installation source for Python 2.7 and 3.3, as well as Postgres 
9.2 and both MySQL 5.5 and MariaDB 5.5, and works for RHELs 6.2-6.4.

Furthermore, "With the notable exception of Node.js, all Red Hat Software 
Collections components are fully supported under Red Hat Enterprise Linux 
Subscription Level Agreements, are functionally complete, and are intended for 
production use."

https://access.redhat.com/site/documentation/en-US/Red_Hat_Software_Collections/1-Beta/html/1.0_Release_Notes/chap-RHSCL.html

I ran across this announcement via Nick Coghlan.

So, there's a supported version of Python 2.7 and 3.3 for RHEL 6, which should 
make Python deprecation choices easier. I would suggest that the above link get 
some mention in the documentation, as this will make things much easier to sell 
in shops that value stability and support, if this alternative solution is 
better known.

Regards,

---Peter

On Jun 29, 2013, at 5:08 AM, Florian Apolloner  wrote:

> Hi,
> 
> On Friday, June 28, 2013 4:17:22 PM UTC+2, Aymeric Augustin wrote:
> As far as I can tell, there's a consensus on dropping support for Python 2.6. 
> That will allow us to remove the vendored copy of unittest2 and to take 
> advantage of datastructures introduced in Python 2.7 like OrderedDict.
> 
> Oh yes, getting rid of our vendored unittest2 is totally worth it (debugging 
> failures when someone imports from below django.utils.unittest2 is no fun)!
> 
> Cheers,
> Florian
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

RFC: "UPSERT" in PostgreSQL

[Peter Geoghegan]

Hello,

I am a PostgreSQL major contributor, currently undertaking development
of a feature sometimes called "UPSERT" for PostgreSQL.

Jacob Kaplan-Moss is an acquaintance and co-worker, and I know that
it's certainly something that interests him personally - presumably he
has some ideas on how an UPSERT-like feature could be used by Django.
Beyond that, I don't have a good sense of what the level of interest
is in the Django community. I would like to reach out and get feedback
on the syntax that I've proposed on the pgsql-hackers development
list. Certainly, I've put a lot of work into this, and expect to put a
lot more in, so obviously it's important that we not make any missteps
with user-visible semantics. I've used Django a bit in the past, and
my general impression is that the Django development community has
made sound technical decisions, so I'm happy to take your concerns as
representative of the concerns of ORM authors and web frameworks
generally.

This is a non-standard syntax that is somewhat comparable to MySQL's
INSERT ... ON DUPLICATE KEY UPDATE, while being more flexible and
safe. The SQL standard's MERGE statement is kind of weird, and has a
lot of baggage from trying to serve multiple use-cases, so I avoided
trying to implement that, preferring to focus on something that has
simple atomic insert-or-update semantics - what people seem to
actually want.

I would like to get a sense of:

* Would you consider the syntax that I've proposed a good one?

* If it was available, would you use it in future versions of Django?
Do you think the plugins ecosystem could take advantage of it sooner?
Is the demand there?

* What could be better about the feature?

* How are you using the MySQL feature (INSERT ... ON DUPLICATE KEY
UPDATE), if at all? Do you think it would be useful to have some
degree of compatibility with it? Why or why not?

I've built html user-facing documentation, which is publicly
available. This page is probably of most interest -- there is
extensive discussion of the new "ON CONFLICT UPDATE/IGNORE" clause:

http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/on-conflict-docs/sql-insert.html

These may be of some interest (search for "on conflict" to see the new
references to the feature):

http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/on-conflict-docs/transaction-iso.html
http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/on-conflict-docs/ddl-inherit.html
http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/on-conflict-docs/sql-createrule.html
http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/on-conflict-docs/trigger-definition.html
http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/on-conflict-docs/sql-createtrigger.html
http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/on-conflict-docs/index-unique-checks.html
http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/on-conflict-docs/sql-createview.html
http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/on-conflict-docs/postgres-fdw.html

If you feel like actually trying out my patch, you can download the
latest version of the patchset from:

http://www.postgresql.org/message-id/CAM3SWZRvkCKc=1Y6_Wn8mk97_Vi8+j-aX-RY-=msrjvu-ec...@mail.gmail.com

You'll need to build PostgreSQL from the git master branch (which
includes dependencies on things like Flex and Bison), with the patch
set applied. There are guides to doing this on the internet, including
this one: http://www.postgresql.org/docs/devel/static/sourcerepo.html

Thanks!
-- 
Peter Geoghegan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAM3SWZSAAK-nSpBuFDpz5KDGPJxNRAE7OGe2sf30Zu0UYCkwNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: RFC: "UPSERT" in PostgreSQL

[Peter Geoghegan]

Hi Alex,

On Sat, Sep 27, 2014 at 5:48 PM, Alex Gaynor  wrote:
> Thanks for reaching out about this!

No problem. I'm not sure if you recall, but we actually met before, in
San Francisco during Waza 2013.

> From the docs, the syntax looks pretty reasonable, it would be nice to see
> what some examples look like though.

There are a couple of examples at the end of the sql-insert.html
INSERT reference page. There could probably stand to be more. There
isn't an example featuring the use of a WHERE clause, though.

The WHERE clause is a bit odd because It is only evaluated on a
conclusively visible, locked row version (and if the predicate isn't
satisfied, the row is still locked, unlike a regular UPDATE). So,
potentially, you could have the predicate satisfied, where the
command's MVCC snapshot would not see a row version that you'd expect
to be satisfied by it. It might just so happen that a later row
version - the latest one - did happen to be satisfied by the predicate
at the same time, because some other session updated the row in a way
that made that the case. This is kind of esoteric, but is a new thing.
Although there have always been similar odd things for regular
UPDATEs. It's also kind of a new thing that you can update something
that is committed, and exists, even though *no* version is visible to
the command's MVCC snapshot. You have to be using READ COMMITTED for
this to happen, though, and if you are, the next command will have a
new snapshot anyway, and so it's probably a pretty academic concern
for Django people in practice.

UPSERT is more or less about reconciling two different ideas of
reality: The snapshot isolation idea, and the physical, objective
reality of whether or not an index tuple exists in a unique index at
this time. Spookiness like this is inevitable, unless you throw an
error instead, which I strongly consider to be a cop-out. If you
wanted that, you'd have used a higher isolation level.

> Yes, I think so:
> https://docs.djangoproject.com/en/dev/ref/models/querysets/#update-or-create
> exists, but right now it's manually implemented using savepoints (IIRC) -- I
> think strictly speaking it isn't safe.

I recall talking to a client about a race condition within
get_or_create() back in my consulting days.

The rule of thumb with the subtransaction looping pattern is that you
have to have a unique index defined to determine when a duplicate is
inserted according to your particular idea of a duplicate (obviously),
and you must be prepared to retry. So typically you update, then you
insert. Loop until one of those two works. If you just try both once,
there are still race conditions.

What I think would be particularly interesting to hear is your level
of interest in the optional "WITHIN unique_index_name" clause. The
idea here is that you can name a unique index directly, and have that
explicitly be the place where the violation is expected, if anywhere
(there ought to be an expectation of having such a violation be in one
place, or else surprising things can happen).

Now, I'm sure the first thing you'll say, as others have is: "Can't it
be the name of some columns instead, so that Postgres figures out
which unique index I mean"? It turns out that that's quite ticklish in
certain edge cases (e.g. partial unique indexes with BEFORE triggers).
We might come up with a better way that's fully general, but I'm not
holding my breath.

> I think even under MySQL it doesn't use the native support for this feature,
> having it in PostgreSQL as well would be good motivation.

Cool.

-- 
Peter Geoghegan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAM3SWZQx%3DR2HxdSMBNTM1XFY9phyj0kq4wysRaFykvPVqdULaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: RFC: "UPSERT" in PostgreSQL

[Peter Geoghegan]

On Sat, Sep 27, 2014 at 6:22 PM, Shai Berger  wrote:
> Upon reading the docs, I was a little surprised to see that in terms of
> triggers etc, the operation is always considered an INSERT. I would expect it
> to be considered an insert for BEFORE INSERT or INSTEAD OF INSERT triggers,
> but if conflict resolution turns it into an UPDATE, I'd expect to see it
> handled as an UPDATE from that point on (definitely INSTEAD OF UPDATE and 
> AFTER
> UPDATE triggers, maybe even BEFORE UPDATE). That is the semantics we have now
> (this is a general remark, not particulary Django-oriented; Django does not
> use triggers on PG as far as I know, and only uses them elsewhere to implement
> serial keys).
>
> Could you explain the reasoning behind the described behavior?

per-row BEFORE triggers from insert will fire even when we go to
update (but not AFTER triggers from INSERT). We need to know what
we're actually inserting before inserting/deciding to update. So
BEFORE triggers must fire, because in principle (and, indeed,
typically), they do modify the tuple being inserted. At the same time,
that's user-defined code often entirely outside our ability to
nullify.

The statement-level trigger stuff (i.e. the idea that ON CONFLICT
UPDATE never fires an UPDATE statement level trigger) is for
consistency with user-defined rules, where we're really compelled to
have INSERT...ON CONFLICT UPDATE just be seen as an UPDATE. But I
admit that that isn't a very satisfactory state of affairs for people
who are using per-statement triggers for auditing and things like
that, and I wouldn't be surprised if that was revised.
-- 
Peter Geoghegan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAM3SWZS89AL2afHEOT2nn6B46OokpzoHs0HW5--GFLXQkUJY0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: RFC: "UPSERT" in PostgreSQL

[Peter Geoghegan]

On Sat, Sep 27, 2014 at 6:33 PM, Peter Geoghegan  wrote:
> The statement-level trigger stuff (i.e. the idea that ON CONFLICT
> UPDATE never fires an UPDATE statement level trigger) is for
> consistency with user-defined rules, where we're really compelled to
> have INSERT...ON CONFLICT UPDATE just be seen as an UPDATE


Excuse me. I mean where we're really compelled to have INSERT...ON
CONFLICT UPDATE just be seen as an **INSERT**.

-- 
Peter Geoghegan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAM3SWZRoP9%3D-cCJr9GwXmw7SM3THoNP9h2E_CRqc2M%2Bo9Thw%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: RFC: "UPSERT" in PostgreSQL

[Peter Geoghegan]

On Sun, Sep 28, 2014 at 1:51 AM, Petite Abeille
 wrote:
> For diversity's sake, and for the record, I, for one, would definitively 
> rather have the standard MERGE statement instead of yet another 'weird' 
> UPSERT concoction peculiar to Postgres.

A few people have said that, but then when you look at SQL MERGE in
detail it becomes apparent that it is really intended to serve the
bulk loading use-case. I took the time to delineate the differences
between SQL MERGE and what I call UPSERT in detail [1].

Both Oracle and SQL server have SQL MERGE implementations that promise
nothing about atomicity or concurrency, and are known to have race
conditions when used to implement even the simplest upsert-like
operation. Certainly, the SQL standard has nothing to say about MERGE
and concurrency. Teradata, SAP HANA and MySQL have UPSERT-ish features
that make some guarantees, and they're both non-standard.

[1] 
http://www.postgresql.org/message-id/flat/CAM3SWZRP0c3g6+aJ=yydgyactzg0xa8-1_fcvo5xm7hrel3...@mail.gmail.com#CAM3SWZRP0c3g6+aJ=yydgyactzg0xa8-1_fcvo5xm7hrel3...@mail.gmail.com

-- 
Peter Geoghegan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAM3SWZSiJUcipFqaM%2BXVm1dwNHDemRtQ33vWA93HiVbfFoKLKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: RFC: "UPSERT" in PostgreSQL

[Peter Geoghegan]

On Sun, Sep 28, 2014 at 4:44 AM, Petite Abeille
 wrote:
> Again, your house, your choice. But it seems a bit self-indulgent to concoct 
> your very own take on MERGE, with baroque syntax, peculiar semantic, and all, 
> just because some abstract aspects of the MERGE specification is not to you 
> liking... rather self-defeating altogether.

Self-indulgent? I thought that I did it for the reasons that I
described in enormous detail in the mail I linked to.

Here is how you make Oracle do an upsert reliably:

https://stackoverflow.com/questions/237327/oracle-how-to-upsert-update-or-insert-into-a-table/2249#2249

Would you be happier with that?

-- 
Peter Geoghegan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAM3SWZSGk14ioYSjnAXH7xNpc_TJM6S0e0MYespvFd6OAny2Xw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: RFC: "UPSERT" in PostgreSQL

[Peter Geoghegan]

On Sun, Sep 28, 2014 at 12:44 PM, Petite Abeille
 wrote:
> I would be happier with a clean MERGE statement implementation in Postgres, 
> yes. And yes, I have followed Postgres' agonizing debate over the years about 
> the subject.  But I personally think it has been framed in the wrong light 
> since the very beginning and that Postgres has convince itself that it 
> somehow cannot support MERGE. Therefore it will not.

I don't know where you've been getting your information from.

I think Postgres can and should support MERGE too.  MERGE isn't harder
-- it's easier, because there is no need to prevent the kind of race
conditions that you get described in the stack overflow thread I
linked to. Oracle's docs describe MERGE as:

"This statement is a convenient way to combine multiple operations. It
lets you avoid multiple INSERT, UPDATE, and DELETE DML statements."

And that's all it is! It's useful for bulk loading/data warehousing,
mostly. I don't quite understand why many people think that MERGE is
useful for implementing UPSERT. It isn't documented to do anything
special in the face of concurrency. I think that there is an
incredible amount of misinformation about this topic floating around.
The various vendors that have a MERGE feature should have clearly
indicated that MERGE isn't useful for implementing an UPSERT, but they
didn't, and so the problem persists.

-- 
Peter Geoghegan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAM3SWZSZGyFMK9zUt23Enf%3DhkvEEyWtc93N7tvvEon%2BMhPaV_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.