Re: Admin patches

[Adam V.]

I have a pending admin patch too: http://code.djangoproject.com/ticket/11651
(With tests and docs, though probably needs some better function
names.)

-- 
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 Related-Object Links in Admin

[Simon Meers]

On 25 May 2010 07:50, Simon Meers  wrote:
>
> I've uploaded some screenshots [1] of the new patch for #13163 [2] and
> #13165 [3] in action, to allow people to see the affect without
> necessarily applying the changes.
>
> These enhancements have *vastly* improved the navigability of the
> admin interface between related objects.
>
> Please have a look and let me know if you have concerns or suggestions
> for improvement. The design decisions are documented in the tickets.
>
> [1] http://share.simonmeers.com/django_related_changelinks/
> [2] http://code.djangoproject.com/ticket/13163
> [3] http://code.djangoproject.com/ticket/13165


I'm guessing DjangoCon.eu week wasn't the ideal time to send this.
Loads of people did check the screenshots out though. Anyone have
concerns or suggestions?

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

[Jacob Kaplan-Moss]

Hey Sebastian --

Okay, turned out I had a moment now. I've reviewed your tickets. See
each one for particular comments, but in general they look good.

However, they're all missing documentation and tests, which need to be
present before they can be checked in. If one of these tickets line up
with a core developer's priorities it's possible that s/he'll write
those for you, but if you want to maximize the chances of getting the
patch applied you'll want to provide us with docs and tests yourself.

Thanks!

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-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: Admin patches

[Jacob Kaplan-Moss]

Hey Sebastian --

Thanks for the reminder; I'll take a look when I get a moment.

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

Admin patches

[Sebastian Noack]

Hi,

it's long time ago, that I have contributed code to django. But at the
moment I work at the admin pages of a django-driven web site. And
because of even though django's admin is powerful, it still needs a lot
of improvement. So I have started to write a few patches. I have
created a ticket with a detailed description, for each patch [1]. But
didn't have got any feedback yet. Is there someone responsible for the
admin at the moment, I could put into CC of my tickets and get some
feedback from?

[1] 
http://code.djangoproject.com/query?reporter=~sebastian_noack=django.contrib.admin


Regards
Sebastian Noack



signature.asc
Description: PGP signature

Re: Query Refactor Status Update

[Waldemar Kornewald]

On Tue, Jun 8, 2010 at 8:55 PM, Alex Gaynor  wrote:
> On Tue, Jun 8, 2010 at 12:11 PM, Waldemar Kornewald
>  wrote:
>> On Tue, Jun 8, 2010 at 7:03 PM, Alex Gaynor  wrote:
>>> On Tue, Jun 8, 2010 at 2:37 AM, Waldemar Kornewald  
>>> wrote:
 Why did you revert the AutoField patch? BTW, in the Django-nonrel
 patch you'll find a few other changes which were related to AutoField:
 ForeignKey needs to find out the actual database type instead of
 having a hard-coded IntegerField. We added related_db_type() for this
 purpose. Maybe you can reuse or adapt some of our code. Still, Django
 has a few unit tests which assume that assigning a string to an
 AutoField will fail, so we'll need to find a solution for that
 (probably by fixing the unit tests).

>>>
>>> No, the unittests are quite correct in this instance.  I've gone back
>>> and forth on this, but I believe the semantics of AutoField are "auto
>>> incrementing field" not "automatically assigned field", and as such
>>> the integer validation (and the fact that it occurs early) is a part
>>> of the API and semantics and the tests are correct.  Therefore it's my
>>> intent to add an NativeAutoField, which is basically whatever the DB's
>>> native auto field is, and has corrospondingly looser constraints,
>>> pending a discussion with Russ.
>>
>> Would this NativeAutoField become the default primary key field from
>> now on or would MongoDB users have to manually specify that field? The
>> former would be ok. The latter would make code reuse more difficult.
>
> No, there is far too much code out there that relies on the assumption
> that the default pk is an integer (and validated as such), including
> (but not limited to: the tests).  I've long been of the opinion you
> can't just expect code to be portable across entirely different
> paradigms of databases and have it magically expected to work.

By not supporting string-based primary keys the MongoDB and SimpleDB
communities will have to maintain their own version of all Django apps
which are already App Engine compatible. Also, writing code for
MongoDB and SimpleDB and many other backends will become more annoying
because you have to explictly specify a NativeAutoField in all of your
models.

By supporting string-based primary keys many existing Django apps can
work unmodified and those that don't work only need a few *trivial*
(!) changes which are even backwards-compatible, so SQL code would
continue to work and unit tests would still validate. At least the App
Engine and MongoDB and SimpleDB communities could easily share the
same code because they have very similar query capabilities. Most
probably many more backends could join. This is a ***huge*** and very
***cheap*** advantage and we shouldn't just throw it away.

FYI, the admin interface, contrib.auth, contrib.sessions,
contrib.sites, etc. work unmodified with our MongoDB backend. If
Django requires an explicit NativeAutoField we all lose those
features. Also, the Django-nonrel website
(http://www.allbuttonspressed.com/) works unmodified on App Engine,
MongoDB, and SQL and we didn't even try to design it like that, so
it's very well possible to write "ultra-portable" apps, even if
they're only simple apps. Moreover, many reusable Django apps don't
explicitly use primary keys in their queries, so they don't have an
AutoField problem, at all.

The point is that we can very well expect that *NoSQL*-compatible
model code will magically work across a broad set of *NoSQL*
databases. SQL code is a different story, but we can at least create a
standard for NoSQL databases. In the worst case we'd split
compatiblity between simple key-value stores and document DBs with
real query capabilities, but at least within each group code can be
shared. That's still much much better than doubling the number of
incompatible NoSQL Django apps and development concepts.

Bye,
Waldemar Kornewald

-- 
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: Query Refactor Status Update

[Alex Gaynor]

On Tue, Jun 8, 2010 at 12:11 PM, Waldemar Kornewald
 wrote:
> On Tue, Jun 8, 2010 at 7:03 PM, Alex Gaynor  wrote:
>> On Tue, Jun 8, 2010 at 2:37 AM, Waldemar Kornewald  
>> wrote:
>>> Why did you revert the AutoField patch? BTW, in the Django-nonrel
>>> patch you'll find a few other changes which were related to AutoField:
>>> ForeignKey needs to find out the actual database type instead of
>>> having a hard-coded IntegerField. We added related_db_type() for this
>>> purpose. Maybe you can reuse or adapt some of our code. Still, Django
>>> has a few unit tests which assume that assigning a string to an
>>> AutoField will fail, so we'll need to find a solution for that
>>> (probably by fixing the unit tests).
>>>
>>
>> No, the unittests are quite correct in this instance.  I've gone back
>> and forth on this, but I believe the semantics of AutoField are "auto
>> incrementing field" not "automatically assigned field", and as such
>> the integer validation (and the fact that it occurs early) is a part
>> of the API and semantics and the tests are correct.  Therefore it's my
>> intent to add an NativeAutoField, which is basically whatever the DB's
>> native auto field is, and has corrospondingly looser constraints,
>> pending a discussion with Russ.
>
> Would this NativeAutoField become the default primary key field from
> now on or would MongoDB users have to manually specify that field? The
> former would be ok. The latter would make code reuse more difficult.
>
> Bye,
> Waldemar Kornewald
>
> --
> 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, there is far too much code out there that relies on the assumption
that the default pk is an integer (and validated as such), including
(but not limited to: the tests).  I've long been of the opinion you
can't just expect code to be portable across entirely different
paradigms of databases and have it magically expected to work.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

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

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

[Kevin Howerton]

This abstract base class likely is a bit less performant than having
in-db support for cascades in pgsql... though it should give you the
behavior you are seeking.

It should set to default, or null if allowed.

Enjoy.

-k

class ClearOnDelete(models.Model):
   def delete(self):
   related_objects = self._meta.get_all_related_objects()
   for object in related_objects:
   accessor_name = object.get_accessor_name()
   related_accessor = getattr(self.__class__, accessor_name)
   related_accessor_instance = getattr(self, accessor_name)

   if related_accessor.related.field.default is not NOT_PROVIDED:
   for relation in related_accessor_instance.all():
   setattr(relation,
related_accessor.related.field.name,
related_accessor.related.field.default)
   relation.save()

   elif related_accessor.related.field.null:
   for relation in related_accessor_instance.all():
   setattr(relation, related_accessor.related.field.name, None)
   relation.save()
   super(ClearOnDelete, self).delete()

   class Meta:
   abstract = True

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

Re: Proposal: {% include_partial %} template tag

[Gregor Müllegger]

Also +1 from me for extending the include tag instead of having a new one.

Bye default it should keep its behaviour and use the current context
for the included template. Marco's use of a new, clean context
(demonstrated with the snippet below) is also possible to support.

   {% if label %}
   {{ label }}
   {% else %}

 You can just pass in an empty string, like one of the following three examples:

{% include "part.html" with label= title=obj.title %}
{% include "part.html" with label="" title=obj.title %}
{% include "part.html" with "" as label and obj.title as title %}

(I don't want to propose the implementation of all three syntaxes. I
just want to demonstrate that all possible syntaxes can handle Marco's
usecase.)

--
Servus,
Gregor Müllegger

2010/6/8 burc...@gmail.com :
> I'd suggest to change both include and with/blocktrans syntax into
> more programmer-friendly style:
>
> {% include "part.html" title=obj.title|capfirst main_class="large" %}
>
> This is both more dense, and from quick grasp you can see where are
> the delimiters ("as" is not so good for this).
>
> Also I think we need an argument to tell that outer context is passed inside.
>
> On Tue, Jun 8, 2010 at 11:30 PM, Gonzalo Saavedra
>  wrote:
>> I'm +1 on the optional "with" parameter for {% include %}. -1 on
>> adding a new tag for this.
>>
>> I also use {% with %}{% include %} a lot in templates but we should
>> follow with/blocktrans syntax for consistency:
>>
>>  {% include "part.html" with obj.title|capfirst as title and "large"
>> as main_class %}
>>
>>
>> A related proposal for the "with" tag: It'd be nice to support more
>> than one variable definition (as blocktrans does):
>>
>>  {% with "a" as var1 and "b" as var2 %}...{% endwith %}
>>
>> The current solution is nesting "with" tags, which is not very pretty.
>>
>>
>> gonz.
>>
>>
>> 2010/6/8 Marco Louro :
>>> Gabriel,
>>>
>>> I only made that decision because I didn't see the need to have whole
>>> context, and the only time I have needed it was because of the {%
>>> csrf_token %}. This is just my use-case, but I understand that other
>>> people might want to use it differently. I don't think it makes much
>>> of a difference, a clean context may avoid some collisions from time
>>> to time, but it may have bigger drawbacks for other people.
>>>
>>> Hi Jeliuc,
>>>
>>> No, I don't.
>>>
>>> On Jun 7, 7:59 pm, Gabriel Hurley  wrote:
 Extending the include tag seems like a fantastic idea! I end up
 writing the {% with %}{% include %} combo all the time for my reusable
 template snippets.

 However, I feel like selectively clearing the context inside a
 template tag is asking for trouble and/or confusion. It also sounds
 like it goes against Django's "templates require no knowledge of
 programming" principle. While I can see how you might run into context
 name collisions in a *very* large or complicated project, the right
 solution there seems like it ought to be to clean up your context and/
 or templates outside of the template itself... Even in projects with
 dozens of installed apps (both my own and third-party ones mixed
 together) I've never had that problem where two minutes of tweaking
 couldn't fix it for good.

 I'm certainly not saying you don't have a use case for it, or that it
 wouldn't be extremely helpful to you. Just that having a tag that
 clears the context sounds fishy to me...

 All the best,

     - Gabriel

 On Jun 7, 10:52 am, Marco Louro  wrote:



 > I'd prefer extending the {% include %} tag actually, but didn't of
 > that in the first place.
>> [...]
>>
>> --
>> 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.
>>
>>
>
>
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: bu...@live.com
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=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, 

Re: Proposal: {% include_partial %} template tag

[burc...@gmail.com]

I'd suggest to change both include and with/blocktrans syntax into
more programmer-friendly style:

{% include "part.html" title=obj.title|capfirst main_class="large" %}

This is both more dense, and from quick grasp you can see where are
the delimiters ("as" is not so good for this).

Also I think we need an argument to tell that outer context is passed inside.

On Tue, Jun 8, 2010 at 11:30 PM, Gonzalo Saavedra
 wrote:
> I'm +1 on the optional "with" parameter for {% include %}. -1 on
> adding a new tag for this.
>
> I also use {% with %}{% include %} a lot in templates but we should
> follow with/blocktrans syntax for consistency:
>
>  {% include "part.html" with obj.title|capfirst as title and "large"
> as main_class %}
>
>
> A related proposal for the "with" tag: It'd be nice to support more
> than one variable definition (as blocktrans does):
>
>  {% with "a" as var1 and "b" as var2 %}...{% endwith %}
>
> The current solution is nesting "with" tags, which is not very pretty.
>
>
> gonz.
>
>
> 2010/6/8 Marco Louro :
>> Gabriel,
>>
>> I only made that decision because I didn't see the need to have whole
>> context, and the only time I have needed it was because of the {%
>> csrf_token %}. This is just my use-case, but I understand that other
>> people might want to use it differently. I don't think it makes much
>> of a difference, a clean context may avoid some collisions from time
>> to time, but it may have bigger drawbacks for other people.
>>
>> Hi Jeliuc,
>>
>> No, I don't.
>>
>> On Jun 7, 7:59 pm, Gabriel Hurley  wrote:
>>> Extending the include tag seems like a fantastic idea! I end up
>>> writing the {% with %}{% include %} combo all the time for my reusable
>>> template snippets.
>>>
>>> However, I feel like selectively clearing the context inside a
>>> template tag is asking for trouble and/or confusion. It also sounds
>>> like it goes against Django's "templates require no knowledge of
>>> programming" principle. While I can see how you might run into context
>>> name collisions in a *very* large or complicated project, the right
>>> solution there seems like it ought to be to clean up your context and/
>>> or templates outside of the template itself... Even in projects with
>>> dozens of installed apps (both my own and third-party ones mixed
>>> together) I've never had that problem where two minutes of tweaking
>>> couldn't fix it for good.
>>>
>>> I'm certainly not saying you don't have a use case for it, or that it
>>> wouldn't be extremely helpful to you. Just that having a tag that
>>> clears the context sounds fishy to me...
>>>
>>> All the best,
>>>
>>>     - Gabriel
>>>
>>> On Jun 7, 10:52 am, Marco Louro  wrote:
>>>
>>>
>>>
>>> > I'd prefer extending the {% include %} tag actually, but didn't of
>>> > that in the first place.
> [...]
>
> --
> 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.
>
>



-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

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

Re: Proposal: {% include_partial %} template tag

[Łukasz Rekucki]

On 8 June 2010 18:30, Gonzalo Saavedra  wrote:
> I'm +1 on the optional "with" parameter for {% include %}. -1 on
> adding a new tag for this.
>
> I also use {% with %}{% include %} a lot in templates but we should
> follow with/blocktrans syntax for consistency:
>
>  {% include "part.html" with obj.title|capfirst as title and "large"
> as main_class %}
Was about to propose the same thing :)

> A related proposal for the "with" tag: It'd be nice to support more
> than one variable definition (as blocktrans does):
>
>  {% with "a" as var1 and "b" as var2 %}...{% endwith %}
>
> The current solution is nesting "with" tags, which is not very pretty.
>

As the next step to make something happen is to create a ticket, I
found this on trac: http://code.djangoproject.com/ticket/7817

I'm willing to improve the existing patch, so I assigned it to myself.
The ticket is marked as DDN, so I guess this thread is a request to
accept it.

-- 
Łukasz Rekucki

-- 
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: Query Refactor Status Update

[Waldemar Kornewald]

On Tue, Jun 8, 2010 at 7:03 PM, Alex Gaynor  wrote:
> On Tue, Jun 8, 2010 at 2:37 AM, Waldemar Kornewald  
> wrote:
>> Why did you revert the AutoField patch? BTW, in the Django-nonrel
>> patch you'll find a few other changes which were related to AutoField:
>> ForeignKey needs to find out the actual database type instead of
>> having a hard-coded IntegerField. We added related_db_type() for this
>> purpose. Maybe you can reuse or adapt some of our code. Still, Django
>> has a few unit tests which assume that assigning a string to an
>> AutoField will fail, so we'll need to find a solution for that
>> (probably by fixing the unit tests).
>>
>
> No, the unittests are quite correct in this instance.  I've gone back
> and forth on this, but I believe the semantics of AutoField are "auto
> incrementing field" not "automatically assigned field", and as such
> the integer validation (and the fact that it occurs early) is a part
> of the API and semantics and the tests are correct.  Therefore it's my
> intent to add an NativeAutoField, which is basically whatever the DB's
> native auto field is, and has corrospondingly looser constraints,
> pending a discussion with Russ.

Would this NativeAutoField become the default primary key field from
now on or would MongoDB users have to manually specify that field? The
former would be ok. The latter would make code reuse more difficult.

Bye,
Waldemar Kornewald

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

[Jeremy Dunck]

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

-- 
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: Query Refactor Status Update

[Alex Gaynor]

On Tue, Jun 8, 2010 at 2:37 AM, Waldemar Kornewald  wrote:
> Hi Alex,
>
> On Jun 7, 9:35 pm, Alex Gaynor  wrote:
>> As you can see the fruits of these efforts have already begun to land
>> in my branch, and I suspect that the multidb refactorings of last year
>> have left us in a better state than I appreciated: while the concepts
>> and data structures used in the Query class are relational/SQL biased
>> (joins, where vs. having, etc.), the data itself is entirely backend
>> neutral.  This means that getting a "stupid" MongoDB backend that can
>> handle trivial filters should be relatively easy, and then it can be
>> evolved to work with the better datastructures I'll be refactoring
>> Queyr to eventually use.
>
> Did you already take a look at our MongoDB backend for Django-nonrel:
> http://github.com/aparo/django-mongodb-engine
> This could save you some time.
>
> Also, maybe you'll find it helpful to see what we had to change in
> Django to get that backend to work:
> https://docs.google.com/leaf?id=0B3LqunL-SCJJNTNiNWE3ZmUtYWIxZi00ZWExLTk4YTktYjM4MzNiZTA0MGNh=en
> I guess by now you're not suprised by the size of the patch,
> anymore. ;) You'll certainly find a few similarities to your branch
> (like the AutoField change or has_results()).
>
> Couldn't some parts of has_results() be reused by NoSQL backends? For
> example, clear_ordering() and set_limits() are completely independent
> of the backend itself.
>

Maybe, but that's really a backend level semantic, it's a trivial
amount of code so I'm not going to worry about some abstraction for
it.

> Why did you revert the AutoField patch? BTW, in the Django-nonrel
> patch you'll find a few other changes which were related to AutoField:
> ForeignKey needs to find out the actual database type instead of
> having a hard-coded IntegerField. We added related_db_type() for this
> purpose. Maybe you can reuse or adapt some of our code. Still, Django
> has a few unit tests which assume that assigning a string to an
> AutoField will fail, so we'll need to find a solution for that
> (probably by fixing the unit tests).
>

No, the unittests are quite correct in this instance.  I've gone back
and forth on this, but I believe the semantics of AutoField are "auto
incrementing field" not "automatically assigned field", and as such
the integer validation (and the fact that it occurs early) is a part
of the API and semantics and the tests are correct.  Therefore it's my
intent to add an NativeAutoField, which is basically whatever the DB's
native auto field is, and has corrospondingly looser constraints,
pending a discussion with Russ.

> Bye,
> Waldemar Kornewald
>
> --
> 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.
>
>

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

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

Re: Proposal: {% include_partial %} template tag

[Gonzalo Saavedra]

I'm +1 on the optional "with" parameter for {% include %}. -1 on
adding a new tag for this.

I also use {% with %}{% include %} a lot in templates but we should
follow with/blocktrans syntax for consistency:

  {% include "part.html" with obj.title|capfirst as title and "large"
as main_class %}


A related proposal for the "with" tag: It'd be nice to support more
than one variable definition (as blocktrans does):

  {% with "a" as var1 and "b" as var2 %}...{% endwith %}

The current solution is nesting "with" tags, which is not very pretty.


gonz.


2010/6/8 Marco Louro :
> Gabriel,
>
> I only made that decision because I didn't see the need to have whole
> context, and the only time I have needed it was because of the {%
> csrf_token %}. This is just my use-case, but I understand that other
> people might want to use it differently. I don't think it makes much
> of a difference, a clean context may avoid some collisions from time
> to time, but it may have bigger drawbacks for other people.
>
> Hi Jeliuc,
>
> No, I don't.
>
> On Jun 7, 7:59 pm, Gabriel Hurley  wrote:
>> Extending the include tag seems like a fantastic idea! I end up
>> writing the {% with %}{% include %} combo all the time for my reusable
>> template snippets.
>>
>> However, I feel like selectively clearing the context inside a
>> template tag is asking for trouble and/or confusion. It also sounds
>> like it goes against Django's "templates require no knowledge of
>> programming" principle. While I can see how you might run into context
>> name collisions in a *very* large or complicated project, the right
>> solution there seems like it ought to be to clean up your context and/
>> or templates outside of the template itself... Even in projects with
>> dozens of installed apps (both my own and third-party ones mixed
>> together) I've never had that problem where two minutes of tweaking
>> couldn't fix it for good.
>>
>> I'm certainly not saying you don't have a use case for it, or that it
>> wouldn't be extremely helpful to you. Just that having a tag that
>> clears the context sounds fishy to me...
>>
>> All the best,
>>
>>     - Gabriel
>>
>> On Jun 7, 10:52 am, Marco Louro  wrote:
>>
>>
>>
>> > I'd prefer extending the {% include %} tag actually, but didn't of
>> > that in the first place.
[...]

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

[Thomas Guettler]

Hi,

I think this is the related ticket:
http://code.djangoproject.com/ticket/7539  "Add ON DELETE and ON UPDATE support 
to Django"

Me and a lot of other people are on the cc list of this ticket.

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

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

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: Proposal: {% include_partial %} template tag

[Marco Louro]

Gabriel,

I only made that decision because I didn't see the need to have whole
context, and the only time I have needed it was because of the {%
csrf_token %}. This is just my use-case, but I understand that other
people might want to use it differently. I don't think it makes much
of a difference, a clean context may avoid some collisions from time
to time, but it may have bigger drawbacks for other people.


Hi Jeliuc,

No, I don't.

On Jun 7, 7:59 pm, Gabriel Hurley  wrote:
> Extending the include tag seems like a fantastic idea! I end up
> writing the {% with %}{% include %} combo all the time for my reusable
> template snippets.
>
> However, I feel like selectively clearing the context inside a
> template tag is asking for trouble and/or confusion. It also sounds
> like it goes against Django's "templates require no knowledge of
> programming" principle. While I can see how you might run into context
> name collisions in a *very* large or complicated project, the right
> solution there seems like it ought to be to clean up your context and/
> or templates outside of the template itself... Even in projects with
> dozens of installed apps (both my own and third-party ones mixed
> together) I've never had that problem where two minutes of tweaking
> couldn't fix it for good.
>
> I'm certainly not saying you don't have a use case for it, or that it
> wouldn't be extremely helpful to you. Just that having a tag that
> clears the context sounds fishy to me...
>
> All the best,
>
>     - Gabriel
>
> On Jun 7, 10:52 am, Marco Louro  wrote:
>
>
>
> > I'd prefer extending the {% include %} tag actually, but didn't of
> > that in the first place.
>
> > The clean context implementation was to make sure we don't pass
> > variables we don't want to. One of the use-cases is including form
> > field "templates", so I have code like:
>
> > 
> > 
> >     
> >         {% if label %}
> >         {{ label }}
> >         {% else %}
> >         {{ field.label_tag }}
> >         {% endif %}
> > 
>
> > if there was a "label" variable in the context but not in the
> > parameters, the code above would output the wrong values. There is one
> > problem with not inheriting the context: {% csrf_token %} will fail.
>
> > On Jun 7, 5:35 pm, £ukasz Rekucki  wrote:
>
> > > On 7 June 2010 18:13, Jacob Kaplan-Moss  wrote:> On 
> > > Mon, Jun 7, 2010 at 5:03 AM, Marco Louro  wrote:
>
> > > >> I'd like to propose adding a tag that includes a template with clean
> > > >> context, but can accept parameters that will be added to that
> > > >> context.
>
> > > > Is there a reason to do this as a separate tag? Why not just::
>
> > > >    {% include "some/template.html" with foo=bar baz=spam %}
>
> > > Personally, I would expect this to extend the current context with
> > > "foo" and "bar", render the include and restore foo, bar to old values
> > > (if any). Using a clean context instead is a bit non-obvious to me.
>
> > > --
> > > £ukasz Rekucki

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

Re: Proposal: {% include_partial %} template tag

[Jeliuc Alexandr]

Hi, Marco

Do You use symfony?

On Jun 7, 1:03 pm, Marco Louro  wrote:
> Hi all,
>
> I'd like to propose adding a tag that includes a template with clean
> context, but can accept parameters that will be added to that
> context.
>
> The use-cases are plenty, but I've been using it mostly with forms, as
> it helps to keep the template code DRY and very customizable. We could
> use the {% with %} and {% include %} tags to do the same of course,
> but I think something like {% include_partial "forms/textfield.html"
> field=person_form.first_name label="First Name:" %} is much cleaner.
>
> This is similar to a rails tag called "render_partial" and there's a
> draft athttp://gist.github.com/427116based 
> onhttp://freeasinbeard.org/post/107743420/render-partial-in-django
>
> Thanks

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

Re: Proposal: modular django configuration

[Jeliuc Alexandr]

Hello...
Modular or divided is not so good as You can feel it now, I think...
For example second web framework I use is symfony. And I hate it
because of this as You say "modularity".
While developing big project I have more then 50 open buffers in emacs
only, plus gvim buffers, plus console windows and console tabs. These
all are on concentrated on 4 desktops.
Q: Do I need 10 or more configuration files in addition to these?

On May 28, 2:19 am, "burc...@gmail.com"  wrote:
> Hi everybody,
>
> Everyone loves the way templates are discovered in django.
> No one loves settings.py that much.
>
> This is proposal on how to improve situation significantly.
>
> Configuration facility is suggested in addition to django.conf.settings.
> Configuration is going to be put into conf/ directory of the project
> (or settings/ -- just set config.global.CONFIG).
>
> :: settings.py ::
> from django.conf import config
> from os.path import dirname, abspath, join
> ROOT = dirname(abspath(__name__)) # type 'str'
> INSTALLED_APPS = ...
>
> config.global.ROOT = ROOT
> config.global.CONFIG = join(ROOT, 'conf')
> config.autodiscover()
> # config.global is in fact a synonym for settings
>
> :: conf/global.py ::
> # runs before the app settings
> from django.conf import config
> from os.path import dirname, abspath
> ROOT = config.global.ROOT # type 'str', empty if not set.
> config.global.JQUERY.default = JQUERY = ROOT +
> 'static/js/jquery-1.3.2-min.js' # type 'dict', setting default value
> for missing items
> config.global.JQUERY['1.3.2'] = JQUERY # type 'unordered dict with
> default value', now setting arbitrary key
> config.global.MEDIA += [ROOT + 'static/js/'] # type 'ordered set with
> default value'
> config.global.DATABASES['default'] = {...} # backward-compatibility,
> so using 'default' not .default!
> # Note: after type is set for constant, the type can't be changed.
> # Note: please set to tuple not list if you need a clear sign the
> option won't be additive any more.
>
> :: conf/global_overrides.py ::
> # runs after all other settings but before _overrides, see below
> # is now empty
>
> :: conf/apps/myapp.py ::
> # runs after all app-specific settings
> app.DATABASES['db3'] = {...}
> app.ROUTERS += ['Db3_is_readonly']
>
> :: conf/www_server_com.py
> # runs before app-specific settings
> from django.conf import config
> config.global.MEDIA_ROOT = '/var/site/www.server.com/site_media/'
> config.global.MEDIA_URL = 'media.server.com'
> app.MIDDLEWARE += ['caching.smart_caching_app.SmartCacher']
>
> :: conf/www_server_com_overrides.py
> # runs after app-specific settings
> config.global.JQUERY['1.3.2'] = 'static/packed.js'
> config.global.JQUERY['1.4.2'] = 'static/packed.js'
>
> :: myapp/conf.py ::
> # runs in order specified in INSTALLED_APPS
> from django.conf import config
> app = config.apps.myapp
> app.DEPENDS += ['django.contrib.auth']
> app.STATIC = app.global.ROOT + 'media/myapp/'
> app.IMAGES = app.global.ROOT + 'media/uploads/images/'
> app.THUMBS = app.global.ROOT + 'media/uploads/thumbs/'
> config.global.MEDIA += [app.IMAGES, app.THUMBS, app.JSES, app.CSSES]
> config.global.JQUERY['1.4.2'] = STATIC + 'js/'
> config.global.TAGS += ['app1.templatetags.mytags']
>
> :: myapp/forms.py ::
> from django.conf import config
>
> app = config.apps['myapp']
> class MyForm:
>     class Media:
>         css = app.STATIC + 'css/base.css'
>         js = config.global.JQUERY['1.4.2']
>
> The ultimate order:
>
> django/conf/global.py
> conf/__init__.py
> conf/global.py    #  -- you can also set your own personal order there
> conf/.py
> app1/conf.py # -- single pass is enough, cause applications can both
> provide callbacks for later configuration stages.
> app2/conf.py
> ...
> appN/conf.py
> conf/apps/app1.py
> conf/apps/app2.py
> conf/apps/appN.py
> conf/global_overrides.py
> conf/_overrides.py
>
> * forwww.my-site.comis www_my__site_com (dots replaced with
> underlines, dash with double underline).
> socket.getfqdn() is used for determining current site.
>
> The motivation is simple:
> the bigger your list of application grows, the larger configuration
> you will have!
> Django has more than 100 of different settings options.
> They are not even grouped now.
> I hope such django "built-in" type of configuration will suit 99% of
> the possible Django projects, and will make django community much
> stronger.
>
> I'm going to create a prototype.
>
> Expected benefits:
>  - 3rd-party applications can be used without a bit of touching and
> still customized perfectly.
>  - Application can connect to each other in dynamic way, or provide
> different kinds of plugin points.
>  - Fixed models dependencies can be replaced with dynamic (i.e, each
> application might ask for personal User or UserProfile replacement)
>  - Really simple media setup for both development and production servers.
>  - A number of development and production configurations can coexist
> in the project, without single 'if'
> 

Re: Query Refactor Status Update

[Waldemar Kornewald]

Hi Alex,

On Jun 7, 9:35 pm, Alex Gaynor  wrote:
> As you can see the fruits of these efforts have already begun to land
> in my branch, and I suspect that the multidb refactorings of last year
> have left us in a better state than I appreciated: while the concepts
> and data structures used in the Query class are relational/SQL biased
> (joins, where vs. having, etc.), the data itself is entirely backend
> neutral.  This means that getting a "stupid" MongoDB backend that can
> handle trivial filters should be relatively easy, and then it can be
> evolved to work with the better datastructures I'll be refactoring
> Queyr to eventually use.

Did you already take a look at our MongoDB backend for Django-nonrel:
http://github.com/aparo/django-mongodb-engine
This could save you some time.

Also, maybe you'll find it helpful to see what we had to change in
Django to get that backend to work:
https://docs.google.com/leaf?id=0B3LqunL-SCJJNTNiNWE3ZmUtYWIxZi00ZWExLTk4YTktYjM4MzNiZTA0MGNh=en
I guess by now you're not suprised by the size of the patch,
anymore. ;) You'll certainly find a few similarities to your branch
(like the AutoField change or has_results()).

Couldn't some parts of has_results() be reused by NoSQL backends? For
example, clear_ordering() and set_limits() are completely independent
of the backend itself.

Why did you revert the AutoField patch? BTW, in the Django-nonrel
patch you'll find a few other changes which were related to AutoField:
ForeignKey needs to find out the actual database type instead of
having a hard-coded IntegerField. We added related_db_type() for this
purpose. Maybe you can reuse or adapt some of our code. Still, Django
has a few unit tests which assume that assigning a string to an
AutoField will fail, so we'll need to find a solution for that
(probably by fixing the unit tests).

Bye,
Waldemar Kornewald

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