#3297 (newforms FileField/ImageField) - Feedback requested

[Russell Keith-Magee]

Hi all,

I've just uploaded a potential fix for ticket #3297 - an
implementation of FileField and ImageField for newforms - and I'm
looking for some feedback.

Details for those interested (repeated from the description of the ticket):

* Modifies forms to take a "files" argument, for storage of file
data. This means you no longer have to copy and update your POST
dictionary on submit. You just call MyForm?(request.POST,
request.FILES)

* Introduces an "UploadedFile?" temporary object to store the
submitted file data.

* Modifies the internals of the form_for_model/instance save
method to make field saving more generic, rather than making a special
case of FileField?. This should make writing custom fields with
unusual save requirements much easier.

This patch has 2 potential backwards incompatibilities:

   1. If you are relying upon auto_id being the 2nd argument on a form
(rather than explicitly naming auto_id=False), your rendered forms
will start adding label tags.

   2. If you have written any custom code using value_from_datadict,
you will need to modify those implementations to handle the new files
argument.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: multiple-db-support

[afarnham]

I am definitely interested and would like to see Ben's merged branch
checked in.

Good work Ben, I am sure getting that branch up to date was difficult.

~Aaron

On Jun 4, 11:27 pm, "Ben Ford" <[EMAIL PROTECTED]> wrote:
> Hi JP,
> I've been using your multiple-db-support for sometime now and i wondered if
> you are still actively developing it? I have a couple of suggestions/queries
> to do with a few of my specific needs and I would guess those of others...
> There are a couple of tickets about this on trac, but I might try and do
> some bits independently so I wanted to ask for your feedback...
> - I'd really like if I could define a FK relationship that spans
> databases, at present that will work but the backwards relationship is
> broken and it throws a validation error.
> - I'd like this 'spanning foreignkey' to not break the django ORM... so
> that Model.objects.filter(fk_class__column='whatever') would still work.
> I'm guessing that this would be quite a lot of work... Probably consisting
> of:
> - A new type (or types) of Field, perhaps OtherDBForeignKey or something
>
> - A new type of descriptor for each of these new field types
> - Some new logic in django.db.models.query to catch the case of a db
> spanning relationship and split the queries up
> - Finally some way to build the sql so that it looks like SELECT
> [columns,] from first_table where pk in (list_of_pk_values); the list will
> be generated from a separate query as a result of splitting the queries up
> in the last step.
> What do you think about the amount of work that would be needed to get all
> this working?
> As an aside i have a copy of multiple-db-support that I've merged with trunk
> as of rev 5371, it might be good to get this checked into django so other
> people can work on it, if there's still any interest...
> Thanks in advance,
> Ben
>
> --
> Regards,
> Ben Ford
> [EMAIL PROTECTED]
> +628111880346


--~--~-~--~~~---~--~~
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: Ping: Extend "for" tag to allow unpacking of lists

[Russell Keith-Magee]

On 6/6/07, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> New patch uploaded, taking into account Brian's thoughts (and fixing a
> small bug):
>
> http://code.djangoproject.com/ticket/3523#comment:11

Ok; I've had a chance to look at this now. I've made a couple of minor
modifications, mostly in docs, and to make the parser more forgiving
on whitespace around the separating commas.

Unless there are any objections, I'm happy to check this into trunk.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Ping: Extend "for" tag to allow unpacking of lists

[Jacob Kaplan-Moss]

On 6/7/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Unless there are any objections, I'm happy to check this into trunk.

Meh, I'm barely +0, but don't let my apathy stop you :)

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Russell Keith-Magee not contactable until 27 June

[Russell Keith-Magee]

Hi all,

As I've mentioned on one or two threads, my job requires me to do some
travel over the next few weeks. The place I am traveling won't have
any internet connectivity, so I will be essentially uncontactable from
the 9th of June.

I should be back in the real world somewhere around the 27th of June.
In the meantime, if you could all kindly avoid finding problems with
the testing and serialization frameworks, avoid any life changing
decisions about aggregation functions, and make my apologies to the
users list where appropriate, I'd be much obliged :-)

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Should regroup return a QuerySet?

[Forest Bond]

Hi,

Currently, the regroup template tag returns a list of dicts that look something
like this:

[
  {'grouper': 'thegrouper', 'list': [obj1, obj2, obj3]},
  ...
]

This is fine & correct behavior, and the tag works for both QuerySet's and lists
as inputs.  However, if a QuerySet is passed in, it would be nice to get a
QuerySet out as the 'list' value.  That way, custom methods on the QuerySet
could still be used in the template.  For instance, in my particular
application, I would like to be able to do this:



{% regroup daily_usages by extension as daily_usages_by_extension %}
{% for daily_usages_for_extension in daily_usages_by_extension %}
  {% with daily_usages_for_extension.list.usage_summary as extension_summary %}
  
{{daily_usages_for_extension.grouper}}
{{extension_summary.incoming_quantity}}
{{extension_summary.incoming_duration}}
{{extension_summary.outgoing_quantity}}
{{extension_summary.outgoing_duration}}
{{extension_summary.other_quantity}}
  
  {% endwith %}
{% endfor %}



I can temporarily overcome this obstacle by using another custom QuerySet
method:



{% for usages_for_extension in daily_usages.group_by_extension %}
  {% with usages_for_extension.list.usage_summary as extension_summary %}
  
{{usages_for_extension.grouper}}
{{extension_summary.incoming_quantity}}
{{extension_summary.incoming_duration}}
{{extension_summary.outgoing_quantity}}
{{extension_summary.outgoing_duration}}
{{extension_summary.other_quantity}}
  
  {% endwith %}
{% endfor %}



Clearly, however, the more general solutions to this would be more ideal.  It
seems like other folks might also enjoy this feature?

(It occurs to me now that I could have written an alternative implementation of
the regroup template tag (instead of using my custom QuerySet method).)

What do people think about this?

-Forest


signature.asc
Description: Digital signature

Re: Should regroup return a QuerySet?

[Forest Bond]

On Thu, Jun 07, 2007 at 10:38:52AM -0400, Forest Bond wrote:
> Hi,
> 
> Currently, the regroup template tag returns a list of dicts that look 
> something
> like this:
> 
> [
>   {'grouper': 'thegrouper', 'list': [obj1, obj2, obj3]},
>   ...
> ]
> 
> This is fine & correct behavior, and the tag works for both QuerySet's and 
> lists
> as inputs.  However, if a QuerySet is passed in, it would be nice to get a
> QuerySet out as the 'list' value.  That way, custom methods on the QuerySet
> could still be used in the template.

It also occurs to me that if regroup handled QuerySets as a special case,
large-ish datasets could be regrouped in a much more efficient manner, since the
filter method could be used instead of iterating and testing for equality.

-Forest


signature.asc
Description: Digital signature

Do you know for a Free ...!? Click Here :)

[only freewares]

NoSpyMail 1.1
"SpyMail" refers to any email message sent to you which attempts to
collect information about you, your computer, or your email habits
without your permission. SpyMail is not a new concept. It has been
used by spammers for years to try to better target their Marketing
campaigns.
http://www.onlyfreeantivir.us/nospymail_1_1.php


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

multiple database support and different DB types

[[EMAIL PROTECTED]]

hi, i'm using the multiple DB support branch and i'd like to have one
DB be MySQL and one be sqlite, but i can't, because all of django's
generated SQL conforms to the primary DB type. so in this case all the
queries sent to the sqlite DB have backticks, which causes parsing
errors.

can anyone suggest where i should start if i want to patch in the
ability to generate different SQL for each DB depending on its type?


--~--~-~--~~~---~--~~
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: Proposal: Let session support backends

[Michael Trier]

I'm with Jacob; I've always considered an in memory solution one that
I was willing to live with.  For smaller sites I like to use the
in-memory version of sqlite.  It's easy to implement and works quite
well.  Definitely having the session pluggable will be a huge help.

Michael

On 6/6/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 6/6/07, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> > It sounds great, but memcached is a cache rather than a persistent store,
> > so it doesn't guarantee to be able to give you back the data.  Is it OK for
> > a session to drop because memcached flushed it out?  Or are you assuming you
> > can size your memcached servers so that they never drop a session?
>
> I've always assumed that session data is basically "disposable". Every
> app I've written using sessions won't cause serious problems if the
> sessions get flushed -- the worst that would happen in that users
> would need to log in again.
>
> [I certainly can't take credit for the concept; I first heard it in
> one of Brad Fitzpatrick's (LiveJournal) talks, and I'm sure the ideas
> been around for a while.]
>
> However, that's a good reason to have sessions pluggable -- if
> persistence is important, then you need db sessions.
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Allowing multiple {% block %}s in one template

[Noam]

Hello,

I'm in the process of moving from turbogears to django, and I must say
that it looks very nice. Thanks!

Now to my problem and my suggestion.

I want every page in my site to have a title. I want the title to
appear both in the browser title and in the page itself. An example of
the HTML I want is this:


Bug System - Report a New Bug

Report a New Bug
...



The obvious way to make this happen would have been this template:


Bug System - {% block title %}{% endblock %}

{% block title %}{% endblock %}
{% block body %}{% endblock %}



but it doesn't work, because a block with the same name can't be
defined twice in the same block.

I asked in IRC what should I do, and got two possibilities:
1. Pass the title as an argument to the template.
2. Write the title twice in the template.

The problem with method 1 is that the title doesn't belong to the code
- it belongs to the template.
The problem with method 2 is that you have to write the title twice
(and I saw the DRY principle mentioned in a few places in the docs...)

After thinking about it, I've found another solution. Write this
template, and call it "base_helper.html":


Bug System - {% block title %}{% endblock %}

{% block silly %}{% endblock %}
{% block body %}{% endblock %}



Also write this template, and call it "base.html":

{% extends "base_helper.html" %}
{% block silly %}{% block title %}{% endblock %}{% endblock %}

Now, if you render a template like this:

{% extends "base.html" %}
{% block title %}Page Title{% endblock %}
{% block body %}Page Body{% endblock %}

You'll get the desired result:


Bug System - Page Title

Page Title
Page Body



The obvious problem with this solution is that most people won't think
about it. And most people finding this code will have a hard time
understanding how it works.

(how it works: the second {% block title %} is enclosed by another
block, defined in another template, so you don't have two {% block
title %}s in the same file and everything is ok.)

Let me explain how I understand the "block" algorithm, which will help
me explain why currently multiple blocks with the same name in the
same template aren't allowed and how they can be made allowed.

The block algorithm goes like this. You are given an ordered list of
templates, starting from the most specific one and ending with the
least specific one. You go over them one by one. You also hold a
mapping from a block name to a string.
For each template, you go over it and render it. When encountering a
block, you check if it appears in the mapping. If it doesn't you
render the block, add the result to the rendered page, and also save
the result in your mapping. If it does appear in the mapping, it means
that you already rendered that block, and you ignore the contents of
the block in the template you are handling and replace it with the
saved result.
The result is the rendered last template, with all blocks handled as
described.

Now, why multiple blocks with the same name aren't allowed in the same
template? Because you won't know which one to render and store in the
mapping, and which one to ignore. If two blocks with the same name
appear in two different files, you have no problem - the block in the
more specific template will take precedence.

However, my description of the algorithm suggests how multiple blocks
with the same name in the same file can be handled: just go over them
one by one. The first block may be rendered, if no block with the same
name is defined in a more specific template, and the rest of the
blocks will never be rendered and will always be replaced.

This solution has a problem, though: Who said that the first block in
a template should be considered the meaningful one, and not the last
one, for example? Or, as the zen of python says: In the face of
ambiguity, refuse the temptation to guess.

For this I want to suggest a solution: When multiple blocks are
defined in one template, all the blocks which are not the first block
should be either:
 * the same as the first block, or:
 * empty.

This means that I would be allowed to write:


Bug System - {% block title %}Page Title{% endblock %}

{% block title %}Page Title{% endblock %}
{% block body %}{% endblock %}



or:


Bug System - {% block title %}Page Title{% endblock %}

{% block title %}{% endblock %}
{% block body %}{% endblock %}



but not:


Bug System - {% block title %}Page Title 1{% endblock %}

{% block title %}Page Title 2{% endblock %}
{% block body %}{% endblock %}



(Of course, I could leave both blocks empty.)

What do you think about this idea?

Noam

P.S. I may be able to implement it by myself, but I wanted to get an
approval (or a disapproval, which I hope not) before.


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

Re: Allowing multiple {% block %}s in one template

[SmileyChris]

Another solution is that multiple blocks with the same name inside a
template are allowed as long as the template doesn't extend that block
name (raise an error in that case).

This way, it doesn't matter about the "meaningful" block, because if
it's just the parent template which has two blocks, you only want to
replace all blocks of that name with the one in your child template
doing the extension so there's no worry about ambiguity.


--~--~-~--~~~---~--~~
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: Allowing multiple {% block %}s in one template

[Marty Alchin]

On 6/7/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> Another solution is that multiple blocks with the same name inside a
> template are allowed as long as the template doesn't extend that block
> name (raise an error in that case).
>
> This way, it doesn't matter about the "meaningful" block, because if
> it's just the parent template which has two blocks, you only want to
> replace all blocks of that name with the one in your child template
> doing the extension so there's no worry about ambiguity.

I'm +1 on this approach. That's how I would expect it to be most
commonly used (it's how I was hoping it would work), and it would
avoid template designers having to worry as much about how the innards
work.

-Gul

--~--~-~--~~~---~--~~
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: Allowing multiple {% block %}s in one template

[Ilya Semenov]

+1 on that. Have been in the same situtation and came up with the
exactly same approach on my mind.
Perhaps http://code.djangoproject.com/ticket/1513 should be reopened?


--~--~-~--~~~---~--~~
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: Should regroup return a QuerySet?

[Ilya Semenov]

> It also occurs to me that if regroup handled QuerySets as a special case,
> large-ish datasets could be regrouped in a much more efficient manner, since 
> the
> filter method could be used instead of iterating and testing for equality.

First, there will be no perfomance gain at all.

Consider the current regroup running at most 1 query:
SELECT * FROM app_model;

The proposed behaviour would run 1+N queries, first for getting
different grouping values:
SELECT DISTINCT(grouper_field) FROM app_model;
and then a separate query for each of the grouping values:
SELECT * FROM app_model WHERE grouper_field = 'grouping_value_1';
SELECT * FROM app_model WHERE grouper_field = 'grouping_value_2';
...
SELECT * FROM app_model WHERE grouper_field = 'grouping_value_N';
In most conditions that would give more overhead than iterating and
testing for equality in Python.

Second, in multi-threaded environment that would possibly lead to
consitency failures. Consider a concurrent thread changing
grouper_field for some entities. That could lead to the same entity
being shown up twice in two groups.


--~--~-~--~~~---~--~~
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: newforms + editable=False

[rogerdpack]

What I wish existed (and already might, I dunno), is the following:
(we can all wish, right?)

subFormClass  =
form_for_class_with_just_some_fields(ThisVeryLargeClass,
'field_a','field_b','field_c' {'required': True})

and then

subFormInstance = subFormClass()
subFormInstance.save_yourself_by_merging_to_this_pre_existing_instance(thisInstance)
# saves its attributes to that instance.-- this is currently possible
through save_instance, as I do it now -- see http://betterlogic.com/roger/?p=43

and then (still wishing :)
initializedForm = subFormClass(initial=thisInstance)
and also this
boundForm = subFormClass(bind_data=thisInstance)

Then it would automate things very well :)  Any ideas?
-Roger

On Jun 5, 4:36 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On 6/5/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Tue, Jun 05, Malcolm Tredinnick wrote:
>
> > > The number "4" exists as a piece of data, irrelevant of
> > > whether it was created by a user, a machine or a bunny rabbit.
>
> > I hope no animals were harmed for producing this e-mail? ;-)
>
> Only the bunnies. They were asking for it. :-)
>
> Russ %-)


--~--~-~--~~~---~--~~
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: Allowing multiple {% block %}s in one template

[James Bennett]

On 6/7/07, Noam <[EMAIL PROTECTED]> wrote:
> I want every page in my site to have a title. I want the title to
> appear both in the browser title and in the page itself. An example of
> the HTML I want is this:
>
> 
> Bug System - Report a New Bug
> 
> Report a New Bug

This seems like an unusual case, though. Consider what another
template, say, 'bug_detail', would look like:



  Bug System - Bug #43 - Using blocks as variables doesn't work


  Bug #43 - Using blocks as variables doesn't work

Now, in this case the title is obviously going to be pulled from
fields on a "bug" object pulled from the database and, more
importantly, the two "blocks" aren't going to match up (it's common to
include a site name or section name in the 'title' element, but far
less common to include it in a a header).

In the uncommon case of exactly-repeated hard-coded text in the
template, the net effect of this would be to change blocks from part
of the inheritance mechanism into another way to do variables in
templates (in this case, assigned by the template author within the
template).

I realize that's not really what's being asked for here, but I have a
hard time believing it wouldn't be used for that -- rather than
organize data in the view, people would just start defining lots of
blocks up-front and reusing them, variable-fashion, throughout the
template, and we'd be one step closer to having a programming language
instead of a templating language.

Additionally, since I'm pretty sure this is the uncommon case rather
than the common case, I'm not sure it's worth further complicating
template parsing and rendering by allowing blocks to be re-used
arbitrary numbers of times.

Combining these two objections, I'd give it a strong -1.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
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: Should regroup return a QuerySet?

[James Bennett]

On 6/7/07, Ilya Semenov <[EMAIL PROTECTED]> wrote:
> The proposed behaviour would run 1+N queries, first for getting
> different grouping values:

This is a very good point, and I think it's enough to make me -1 on
regroup returning a QuerySet :)

> Second, in multi-threaded environment that would possibly lead to
> consitency failures. Consider a concurrent thread changing
> grouper_field for some entities. That could lead to the same entity
> being shown up twice in two groups.

This is also a tricky bit; in theory the queries would all run in one
transaction and so be guaranteed a consistent view of the data, but
there are some DBs out there which think "transactions" are something
you do at the bank... ;)

-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
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: Should regroup return a QuerySet?

[Adrian Holovaty]

On 6/7/07, Ilya Semenov <[EMAIL PROTECTED]> wrote:
> First, there will be no perfomance gain at all.
> [...]
> Second, in multi-threaded environment that would possibly lead to
> consitency failures. Consider a concurrent thread changing
> grouper_field for some entities. That could lead to the same entity
> being shown up twice in two groups.

Aside from these very good reasons, it wouldn't be a good idea to
couple the template system to the database layer. The template system
shouldn't know anything about QuerySets, or Models, or Managers, or
any other Django-model-specific phenomena.

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.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-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: Ping: Extend "for" tag to allow unpacking of lists

[Adrian Holovaty]

On 6/7/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> On 6/7/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > Unless there are any objections, I'm happy to check this into trunk.
>
> Meh, I'm barely +0, but don't let my apathy stop you :)

+0 from me, too. Go for it, if you'd like.

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.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-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: Should regroup return a QuerySet?

[Forest Bond]

On Thu, Jun 07, 2007 at 01:54:18PM -0700, Ilya Semenov wrote:
> 
> > It also occurs to me that if regroup handled QuerySets as a special case,
> > large-ish datasets could be regrouped in a much more efficient manner, 
> > since the
> > filter method could be used instead of iterating and testing for equality.
> 
> First, there will be no perfomance gain at all.
> 
> Consider the current regroup running at most 1 query:
> SELECT * FROM app_model;
> 
> The proposed behaviour would run 1+N queries, first for getting
> different grouping values:
> SELECT DISTINCT(grouper_field) FROM app_model;
> and then a separate query for each of the grouping values:
> SELECT * FROM app_model WHERE grouper_field = 'grouping_value_1';
> SELECT * FROM app_model WHERE grouper_field = 'grouping_value_2';
> ...
> SELECT * FROM app_model WHERE grouper_field = 'grouping_value_N';
> In most conditions that would give more overhead than iterating and
> testing for equality in Python.

I'm not convinced this is overwhelmingly true, although it may be true for many
of the common use cases.  Certainly, in some significant number of cases (large
data set, small number of grouping values), the database would be quicker, no?

The performance comparision is highly dependent on the particulars of the setup,
though.  If the database connection is slow, you are certainly right.  If not,
do you think that perhaps it might be close?  Isn't it more common for the
database connection to be fast, rather than slow?

There is an obvious, although not incredibly common, use case in which the
current implementation would be decidedly slower: when the grouped lists are
then sliced (assuming a mildly large dataset):

{% for object in grouped.list|slice:"0:10" %}
{% endfor %}

This is more performant since it leverages the laziness of QuerySets, and it
might represent a reasonably common situation: "Show the user a list of the top
10 items for each of the following grouper fields."

Of course, most current implementations of that use case are probably explicitly
making N different queries prior to template evaluation.  It's certainly
possible that doing the grouping at template-time is not something many people
would choose to do.

> Second, in multi-threaded environment that would possibly lead to
> consitency failures. Consider a concurrent thread changing
> grouper_field for some entities. That could lead to the same entity
> being shown up twice in two groups.

Hmm.  Good point.  I hadn't thought of it.  In my application, the field I'm
grouping by does not change once it has been set, so it's a non-issue.

Your second point above confirms for me that the standard regroup tag should not
handle QuerySets as special cases.  However, it does strike me as useful to have
the QuerySet-aware variant around, caveats and all.  I suppose it may not be
useful enough for core.  Any opinion on that?

-Forest


signature.asc
Description: Digital signature

Re: Should regroup return a QuerySet?

[Forest Bond]

On Thu, Jun 07, 2007 at 04:11:41PM -0500, Adrian Holovaty wrote:
> Aside from these very good reasons, it wouldn't be a good idea to
> couple the template system to the database layer. The template system
> shouldn't know anything about QuerySets, or Models, or Managers, or
> any other Django-model-specific phenomena.

Ok, I definately agree here.

(Side thought: is it really that bad for the template system to leverage
QuerySet functionality without requiring it?  It's obviously not as bad as
depending on it.)

I just sent another email in which I ponder the utility of having a second tag,
similar to regroup, but explicitly designed to handle QuerySets.

What about django.db having a templatetags.py? :)

Or maybe django.contrib.dbtemplatetags

-Forest


signature.asc
Description: Digital signature

Re: Should regroup return a QuerySet?

[Adrian Holovaty]

On 6/7/07, Forest Bond <[EMAIL PROTECTED]> wrote:
> What about django.db having a templatetags.py? :)
>
> Or maybe django.contrib.dbtemplatetags

I wouldn't be opposed to something like that -- database-specific
template tags. The question is, which tags would they be? :)

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.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-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: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)

[Honza Král]

Hello,
what is the current status of newforms-admin? We just started
developing a major project with it and we will need the edit_inline
functionality. Is there any chance this will be supported in next few
weeks?

Since we really need newforms-admin for this project, my employer
agreed to pay me to work on the newforms-admin if necessary, so if
there is anything I can do to help I will be glad if you can point me
to some code (I understand you have some draft version) that I could
try and finish. Or, if no code is available, if you could describe
your vision of the feature and then I could try my best to fulfill
it... ;)

Thanks very much in advance...
Honza

On 5/14/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> On 5/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> >
> > What's your ETA on these changes? I finally have some free time this
> > week, and I'd like to work toward getting this branch finalized. If
> > you don't have time to hack on this, let me know where you left off.
>
> I'm still working on the formset-model integration stuff. After that
> it's mostly configuration classes and template changes. I'll have time
> to work on it this week, but I don't expect I'd be able to finish it.
> There's also still some ugliness in the FormSet constructor, but it
> works. If you think you'll have a lot of time, and you want to take
> over, my feelings won't be hurt, but I'll keep working on it until I
> hear otherwise.
>
> Joseph
>
> P.S. What's your status on the other stuff in that branch? I know that
> site.register doesn't handle kwargs for ModelAdmin yet, and I think
> there are a couple of other loose ends, but I figured you just hadn't
> gotten that far yet. I can file tickets as I come across stuff like
> that if you like, but I don't want to harass you with unneccessary
> info.
>
> >
>


-- 
Honza Kr�l
E-Mail: [EMAIL PROTECTED]
ICQ#:   107471613
Phone:  +420 606 678585

--~--~-~--~~~---~--~~
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: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)

[Adrian Holovaty]

On 6/7/07, Honza Král <[EMAIL PROTECTED]> wrote:
> Since we really need newforms-admin for this project, my employer
> agreed to pay me to work on the newforms-admin if necessary, so if
> there is anything I can do to help I will be glad if you can point me
> to some code (I understand you have some draft version) that I could
> try and finish. Or, if no code is available, if you could describe
> your vision of the feature and then I could try my best to fulfill
> it... ;)

Basically, edit_inline is the main thing left. Joseph Kocherhans has
been working on it off-and-on for the past few months. It seems like
he's a bit too busy to devote a lot of time to this, so, Honza, your
help would be much appreciated.

Let's give Joseph some time to comment before going further...

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.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-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: Allowing multiple {% block %}s in one template

[Noam]

On Jun 7, 11:17 pm, SmileyChris <[EMAIL PROTECTED]> wrote:
> Another solution is that multiple blocks with the same name inside a
> template are allowed as long as the template doesn't extend that block
> name (raise an error in that case).
>
> This way, it doesn't matter about the "meaningful" block, because if
> it's just the parent template which has two blocks, you only want to
> replace all blocks of that name with the one in your child template
> doing the extension so there's no worry about ambiguity.

I think that in practice it doesn't matter a lot whether your method
is chosen or mine, since I think that the use case is pretty much what
I described. However, I like my method better since (I think) it keeps
the block algorithm simpler to understand, and "Simple is better than
complex" - it keeps the current algorithm, and clarifies what should
be done if multiple blocks with the same name are encountered in the
same template. My method keeps the fact that in the resulting page,
every block with the same name is replaced with the same content, and
it doesn't add a new restriction about other related templates.

Sorry about my long sentences. I just gave this a bit of thought, and
I think that my method is nicer, and Ilya thinks the same, and both
methods solve the use case just as well, so...


--~--~-~--~~~---~--~~
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: Allowing multiple {% block %}s in one template

[Noam]

On Jun 8, 12:02 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On 6/7/07, Noam <[EMAIL PROTECTED]> wrote:
>
> > I want every page in my site to have a title. I want the title to
> > appear both in the browser title and in the page itself. An example of
> > the HTML I want is this:
>
> > 
> > Bug System - Report a New Bug
> > 
> > Report a New Bug
>
> This seems like an unusual case, though. Consider what another
> template, say, 'bug_detail', would look like:
>
> 
> 
>   Bug System - Bug #43 - Using blocks as variables doesn't work
> 
> 
>   Bug #43 - Using blocks as variables doesn't work
>
> Now, in this case the title is obviously going to be pulled from
> fields on a "bug" object pulled from the database and, more
> importantly, the two "blocks" aren't going to match up (it's common to
> include a site name or section name in the 'title' element, but far
> less common to include it in a a header).
>
I don't think it's uncommon. I wrote a perfectly simple site and
writing the same title at the top of the window and in the page was
the right thing to do. It doesn't have to be the case for all sites,
but it doesn't make it uncommon - the fact is that at least
SmileyChris, Marty, Ilya and I had the same need.

> In the uncommon case of exactly-repeated hard-coded text in the
> template, the net effect of this would be to change blocks from part
> of the inheritance mechanism into another way to do variables in
> templates (in this case, assigned by the template author within the
> template).
>
I don't see how you will be able to use blocks as variables. The only
thing you can do with a block is to display it in the rendered page -
you can't use it in any other way. And if you want to write the same
thing a few times in your page, what's wrong with it?

Also, everything that you would be able to do if my suggestion is
accepted you can do right now, using the trick I described. It's just
pretty ugly.

> I realize that's not really what's being asked for here, but I have a
> hard time believing it wouldn't be used for that -- rather than
> organize data in the view, people would just start defining lots of
> blocks up-front and reusing them, variable-fashion, throughout the
> template, and we'd be one step closer to having a programming language
> instead of a templating language.

This may be a reason to force writing the same content in all blocks
of the same name in a template. However, I don't really understand the
usage you describe - can you give an example?
>
> Additionally, since I'm pretty sure this is the uncommon case rather
> than the common case, I'm not sure it's worth further complicating
> template parsing and rendering by allowing blocks to be re-used
> arbitrary numbers of times.

Just another comment - I'm not sure it will complicate template
parsing a lot. As I said, the same thing can be done in a more ugly
way. It's basically just lifting an unneeded requirement. But this can
be judged by seeing a working implementation.

Noam


--~--~-~--~~~---~--~~
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: multiple database support and different DB types

[[EMAIL PROTECTED]]

I haven't tried this at all myself, as I just use mysql ...but are you
saying that specifying a different DATABASE_ENGINE in the
OTHER_DATABASES entries doesn't work?  Was just making sure you had
tried that.

On Jun 7, 2:02 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> hi, i'm using the multiple DB support branch and i'd like to have one
> DB be MySQL and one be sqlite, but i can't, because all of django's
> generated SQL conforms to the primary DB type. so in this case all the
> queries sent to the sqlite DB have backticks, which causes parsing
> errors.
>
> can anyone suggest where i should start if i want to patch in the
> ability to generate different SQL for each DB depending on its type?


--~--~-~--~~~---~--~~
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: multiple-db-support

[[EMAIL PROTECTED]]

I hadn't really received any response from any active developers in
the project on this... but was slowly attempting to do the merge with
the trunk I spoke to Ben via email... waiting to hear back from
him to verify where he was on the merge, as it sounds as though he has
already got the merge further along than I have... the day after I
started working on it, our network got hacked at our office... which
caused a big ruckus... then my deadline got pushed backso I
haven't had as much time to devote to it as I had hoped.  Anyways...
I'm going to try and collaborate with Ben on this, since appears he
has already gotten farther.

It would be nice if someone might tell either myself or Ben, how we
would go about getting the merged code committed, once it's been
completed and tested or do we just submit it as a patch or
something on the wiki page for this branch?

On Jun 6, 1:02 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> A few weeks back there was a discussion about providing support for
> alternative database usage scenarios in Django and around that time
> another userCaroleZieler(carole.zieler) had offered to do some
> maintenance on the branch.  I don't think she ever received a response
> back and subsequently has struck out on her own to update the multi-db
> branch.  I'd suggest getting in contact so as not to duplicate
> efforts.
>
> On Jun 5, 9:34 am, JP <[EMAIL PROTECTED]> wrote:
>
> > I replied to Ben via email, but for the group, again: multi-db needs a
> > new maintainer. I don't have the time to keep up with merging it, let
> > alone to add new features or complete the documentation. I think Ben
> > has some excellent ideas here and would be a great maintainer
> > candidate.
>
> > JP
>
> > On Jun 5, 12:27 am, "Ben Ford" <[EMAIL PROTECTED]> wrote:
>
> > > Hi JP,
> > > I've been using your multiple-db-support for sometime now and i wondered 
> > > if
> > > you are still actively developing it? I have a couple of 
> > > suggestions/queries
> > > to do with a few of my specific needs and I would guess those of others...
> > > There are a couple of tickets about this on trac, but I might try and do
> > > some bits independently so I wanted to ask for your feedback...
> > > - I'd really like if I could define a FK relationship that spans
> > > databases, at present that will work but the backwards relationship is
> > > broken and it throws a validation error.
> > > - I'd like this 'spanning foreignkey' to not break the django ORM... 
> > > so
> > > that Model.objects.filter(fk_class__column='whatever') would still work.
> > > I'm guessing that this would be quite a lot of work... Probably consisting
> > > of:
> > > - A new type (or types) of Field, perhaps OtherDBForeignKey or 
> > > something
>
> > > - A new type of descriptor for each of these new field types
> > > - Some new logic in django.db.models.query to catch the case of a db
> > > spanning relationship and split the queries up
> > > - Finally some way to build the sql so that it looks like SELECT
> > > [columns,] from first_table where pk in (list_of_pk_values); the list will
> > > be generated from a separate query as a result of splitting the queries up
> > > in the last step.
> > > What do you think about the amount of work that would be needed to get all
> > > this working?
> > > As an aside i have a copy of multiple-db-support that I've merged with 
> > > trunk
> > > as of rev 5371, it might be good to get this checked into django so other
> > > people can work on it, if there's still any interest...
> > > Thanks in advance,
> > > Ben
>
> > > --
> > > Regards,
> > > Ben Ford
> > > [EMAIL PROTECTED]
> > > +628111880346


--~--~-~--~~~---~--~~
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: Design Decision: Dynamic settings.SITE_ID (ref. #4438)

[Malcolm Tredinnick]

On Wed, 2007-06-06 at 21:20 +, [EMAIL PROTECTED] wrote:
> Malcolm:
> 
> We have currently implemented a Middleware Hack to alter the
> settings.SITE_ID
> 
> The problem being that our project is serving more then 10 domain
> names and we are aiming at about 1200 requests/second. We don't want
> to hesitate when the load gets high, to through another App Server to
> handle the traffic.
> 
> I am wondering how this exactly affects the caching? Shouldn't the
> caching be getting and setting based off of settings.SITE_ID? Your
> post scares me and makes me want to dig through all the Django Caching
> code to see how exactly it will break. Maybe we will be the first to
> patch the breakage as it doesn't seem like it should break to me.

Remember that the word caching just means "storing for later use". It
doesn't always mean HTTP caching, which is what I suspect you are
talking about.

There are many places in the code where a settings value is read and
then some action taken and data stored somewhere based on that setting.
For example, the list of installed apps (which is a setting) is used to
populate the global app cache (once!) in django/db/models/loading.py.
The USE_I18N setting is used to determine which translation functions to
install -- we only do that once. Those are two I can think of off the
top of my head; there are other instances, though.

In short, I was using "cached" in the generic Comp Sci sense, not in the
HTTP sense. Sorry for any confusion.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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: Allowing multiple {% block %}s in one template

[Marty Alchin]

I should note that I withdraw my +1. Not only does James bring up some
good points, I just realized that Noam's example can be done without
the whole {%block silly %} thing.

Just to test all this out, I just defined {% block title %} in two
different inherited templates and filled it in in the third template,
and it worked just fine.

structure.html:


My Site: {% block title %}{% endblock %}

{% body theme %}{% endblock %}


body.html:
{% extends 'structure.html' %}
{% block theme %}
{% block title %}{% endblock %}
{% endblock %}

.html
{% extends 'body.html' %}
{% block title %}Page Title{% endblock %}

Obviously there'd be more going on in those, but that demonstrates the
point. The page title gets a prefix, while the content title doesn't,
but both receive the same text, as written in the page template. I've
tested this in both 0.95 and in SVN.

I'd say I'm -0 on this now.

-Gul

--~--~-~--~~~---~--~~
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: Allowing multiple {% block %}s in one template

[SmileyChris]

On Jun 8, 10:33 am, Noam <[EMAIL PROTECTED]> wrote:
> ... However, I like my method better since (I think) it keeps
> the block algorithm simpler to understand, and "Simple is better than
> complex" - it keeps the current algorithm, and clarifies what should
> be done if multiple blocks with the same name are encountered in the
> same template.
Each to their own. I just provided a suggestion since your way just
seemed confusing (perhaps introducing the need for long sentences?).
Especially with the introduction of a strange "all the blocks which
are not the first block should be either the same as the first block,
or empty." rule.

> My method keeps the fact that in the resulting page,
> every block with the same name is replaced with the same content, and
> it doesn't add a new restriction about other related templates.
This isn't really introducing a new restriction, just relaxing a
current one.

> I think that my method is nicer, and Ilya thinks the same, and both
> methods solve the use case just as well, so...
>From the thread, it isn't clear exactly which method Ilya preferred.
You also assume in your following message that I had a "need" for this
- I was merely presenting a more simplistic solution.
Call me +0 on my suggestion, -0 on the overall proposal ;)


--~--~-~--~~~---~--~~
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: Design Decision: Dynamic settings.SITE_ID (ref. #4438)

[Marty Alchin]

On 6/7/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Those are two I can think of off the
> top of my head; there are other instances, though.

For dbsettings at least, I expect a dynamic settings.SITE_ID would be
even more damaging. It loads settings from the database once during
startup and only touches the database again when updating them. So all
"sites" would end up with the same dbsettings, even though they
shouldn't.

When updating them, it would assign them to the appropriate site,
which would then be used throughout that instance. Unfortunately, this
would be reset the next time the server starts, so you'd have to
manually set all your settings on every site every time you start the
server, in order to get them to work properly.

The only around this for dbsettings would be to maintain a dictionary
mapping each SITE_ID to its dbsettings cache. I don't enjoy that
thought, especially since it would be a rare case that someone would
want to do it..

-Gul

--~--~-~--~~~---~--~~
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: Allowing multiple {% block %}s in one template

[James Bennett]

On 6/7/07, Noam <[EMAIL PROTECTED]> wrote:
> I don't see how you will be able to use blocks as variables. The only
> thing you can do with a block is to display it in the rendered page -
> you can't use it in any other way. And if you want to write the same
> thing a few times in your page, what's wrong with it?

{% block site_name %}Zombo.com{% endblock %}
{% block welcome_message %}Welcome! {% endblock %}
{% today_date %}{% now "%m %d, %Y" %}{% endblock %}


{% block site_name %}{% endblock %} - {% block welcome_message
%}{% endblock %} -- {% block today_date %}{% endblock %}



{% block site_name %}{% endblock %} - {% block welcome_message
%}{% endblock %} -- {% block today_date %}{% endblock %}

{% block welcome_message %}{% endblock %} You can do anything at {%
block site_name %}{% endblock %}!

etc., etc.

> Just another comment - I'm not sure it will complicate template
> parsing a lot. As I said, the same thing can be done in a more ugly
> way. It's basically just lifting an unneeded requirement. But this can
> be judged by seeing a working implementation.

The complication will be in rendering of blocks. As it stands,
rendering a block is a (somewhat) simple process because of the "each
block is used once" requirement; there's a fairly limited number of
places you have to look to determine whether the current template is
overriding the block or should pick up content from a parent (and if
so, which parent). Allowing blocks to be reused multiple times could
end up requiring the template system to search a lot more places
before it can reliably make that decision, and that would complicate
rendering and probably make things run more slowly.

-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
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: newforms-admin "plugins"

[Adrian Holovaty]

On 5/28/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> For my policy work, I'd like to be able to add in a separate URL
> handler within each model's registration, so that something like
> /admin/app/policy/ and /admin/app/model/policy/ would give editors
> customized for that location. However, I'm not seeing a way to do
> anything like that, as the URL components are all hard-coded in an
> if/elif block.

I'm running into this problem/limitation in trying to fix
http://code.djangoproject.com/ticket/4450 -- the previous (trunk)
admin overrides the admin URLconf value for "/auth/user/" as a special
case, and newforms-admin doesn't do that yet. So there needs to be a
hook in ModelAdmin for overriding the URL parsing behavior.

It's currently implemented in ModelAdmin.__call__(), but that method
does some other things that you shouldn't have to duplicate. So, maybe
this could be fixed by adding a small hook in there -- handle_url(),
or something. Any thoughts?

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.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-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: newforms + editable=False

[Russell Keith-Magee]

On 6/8/07, rogerdpack <[EMAIL PROTECTED]> wrote:
>
> What I wish existed (and already might, I dunno), is the following:
> (we can all wish, right?)
>
> subFormClass  =
> form_for_class_with_just_some_fields(ThisVeryLargeClass,
> 'field_a','field_b','field_c' {'required': True})

erm.. do you mean the functionality that not only exists, but is documented ?

http://www.djangoproject.com/documentation/newforms/#using-a-subset-of-fields-on-the-form

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: multiple-db-support

[Russell Keith-Magee]

On 6/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> It would be nice if someone might tell either myself or Ben, how we
> would go about getting the merged code committed, once it's been
> completed and tested or do we just submit it as a patch or
> something on the wiki page for this branch?

Initially, I would suggest submitting as a patch. If there isn't
already a ticket for the multi-db feature, open one, and keep the
patch up to date.

Once you demonstrate that you're (1) capable of doing the work, and
(2) are in this for the long haul, we can get you an SVN login for the
branch.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Design Decision: Dynamic settings.SITE_ID (ref. #4438)

[Malcolm Tredinnick]

On Thu, 2007-06-07 at 20:00 -0400, Marty Alchin wrote:
> On 6/7/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > Those are two I can think of off the
> > top of my head; there are other instances, though.
> 
> For dbsettings at least, I expect a dynamic settings.SITE_ID would be
> even more damaging. It loads settings from the database once during
> startup and only touches the database again when updating them. So all
> "sites" would end up with the same dbsettings, even though they
> shouldn't.

No dbsettings depend on SITE_ID, as far as I can see.

I think you are just confusing multiple issues here. This thread is not
at all about making all settings dynamic based on SITE_ID. It was about
making the functionality currently provided by SITE_ID dynamic (just the
value of SITE_ID -- or it's new equivalent).

Regards,
Malcolm



--~--~-~--~~~---~--~~
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: multiple-db-support

[Ben Ford]

Russ,

Can I suggest doing it the other way round in this case. I believe that the
multiple-db-support branch has only a small user base and I haven't had time
to properly test all aspects of the merge, I think it might make it easier
for others to test if they can just svn up. There are some aspects of the
branch that still need work and I think that most people who are using it
recognize this. Also as Carole has expressed an interest in contributing and
also SVK, it would be beneficial to her (and any others) to be able to grab
a local copy of the branch which she can keep in source control as she adds
bits to it.

What do you think?
Ben

On 08/06/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
>
> On 6/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > It would be nice if someone might tell either myself or Ben, how we
> > would go about getting the merged code committed, once it's been
> > completed and tested or do we just submit it as a patch or
> > something on the wiki page for this branch?
>
> Initially, I would suggest submitting as a patch. If there isn't
> already a ticket for the multi-db feature, open one, and keep the
> patch up to date.
>
> Once you demonstrate that you're (1) capable of doing the work, and
> (2) are in this for the long haul, we can get you an SVN login for the
> branch.
>
> Yours,
> Russ Magee %-)
>
> >
>


-- 
Regards,
Ben Ford
[EMAIL PROTECTED]
+628111880346

--~--~-~--~~~---~--~~
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: Design Decision: Dynamic settings.SITE_ID (ref. #4438)

[Marty Alchin]

On 6/7/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> No dbsettings depend on SITE_ID, as far as I can see.

The most recent version takes the current Site into account, using a
ForeignKey to contrib.sites.models.Site. It then uses
Site.objects.get_current() to get the Site for its queries, and as far
as I can tell from its code, get_current() uses settings.SITE_ID to
retrieve that object.

I do realize this wouldn't have any impact on the other Django-proper
settings. But even just changing this one setting would (likely) have
a substantial impact on dbsettings. But, since I haven't actually
tried it, I may well be missing something.

-Gul

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

Send 'text/html' send_mass_mail

[Marinho Brandao]

Hello all,

I have notice some users (like me) need for 'text/html' mime-type in
sendmail (and send_mass_mail, of course), some tickets treats this
subject.

I solved this problem, replacing the following line (78) in
django.core.mail module:

msg = SafeMIMEText(message, 'plain', settings.DEFAULT_CHARSET)

by this (using a new setting, called DEFAULT_EMAIL_MIMETYPE:

mime_type = settings.DEFAULT_EMAIL_MIMETYPE or 'plain'
msg = SafeMIMEText(message, mime_type, settings.DEFAULT_CHARSET)

I notice that the not yet official version, in SVN, haves a new
paradigm, through the class EmailMessage, by the method message(self),
but there is the same problem.

What do you think about my solution?

-- 
José Mário, Mário ou Marinho

http://del.icio.us/marinho
http://www.flickr.com/photos/marinho/
http://marinho.wordpress.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-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: newforms-admin "plugins"

[Marty Alchin]

On 6/7/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I'm running into this problem/limitation in trying to fix
> http://code.djangoproject.com/ticket/4450 -- the previous (trunk)
> admin overrides the admin URLconf value for "/auth/user/" as a special
> case, and newforms-admin doesn't do that yet. So there needs to be a
> hook in ModelAdmin for overriding the URL parsing behavior.

This probably sounds bad, but I'm glad I'm not the only one who's
missing something.

> It's currently implemented in ModelAdmin.__call__(), but that method
> does some other things that you shouldn't have to duplicate. So, maybe
> this could be fixed by adding a small hook in there -- handle_url(),
> or something. Any thoughts?

I admit I haven't done much work or testing with newforms-admin yet,
so I'm not sure how would be best. Looking at ModelAdmin.__call__(), I
wonder if those that if/elif section could reuse something from
urlpatterns. After all, it's just checking URLs and delegating to
views, something we already have a solid system for.

I doubt all of URLconf is needed, but maybe a list of 2-tuples
containing a regular expressions and a callable. Given that
ModelAdmin.__call__ currently passes parts of the URL to each view, it
would include the same kind of group captures that URLconf currently
uses.

I guess I don't know if all of that is necessary. Maybe just moving
that if/elif section to a handle_url() method would be simple enough.
Then subclasses can just override it and use super() to tie into the
stock views.

I guess I'm not sure exactly how would be best, but it's essentially
just a URLconf, so there ought to be something there that can be
reused.

-Gul

--~--~-~--~~~---~--~~
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: newforms-admin "plugins"

[Malcolm Tredinnick]

On Thu, 2007-06-07 at 19:07 -0500, Adrian Holovaty wrote:
> On 5/28/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> > For my policy work, I'd like to be able to add in a separate URL
> > handler within each model's registration, so that something like
> > /admin/app/policy/ and /admin/app/model/policy/ would give editors
> > customized for that location. However, I'm not seeing a way to do
> > anything like that, as the URL components are all hard-coded in an
> > if/elif block.
> 
> I'm running into this problem/limitation in trying to fix
> http://code.djangoproject.com/ticket/4450 -- the previous (trunk)
> admin overrides the admin URLconf value for "/auth/user/" as a special
> case, and newforms-admin doesn't do that yet. So there needs to be a
> hook in ModelAdmin for overriding the URL parsing behavior.
> 
> It's currently implemented in ModelAdmin.__call__(), but that method
> does some other things that you shouldn't have to duplicate. So, maybe
> this could be fixed by adding a small hook in there -- handle_url(),
> or something. Any thoughts?

That would work.

Alternatively (and I suspect this is a variation on what Marty is
suggesting), move all the url processing bit out of __call__() and into
a function that __call__ calls. Then that function can be overridden in
the subclass. Notice that you don't have a similar problem in AdminSite
because the root() method there is only doing URL processing, so it can
be overridden and called via super().

I don't have any really strong preference for one method or the other,
although I probably have a slight preference for the sub-classing
approach if possible. We use both methods (super() calls and hooks)
elsewhere in the code, so neither approach is going to be surprising,
although I'm not sure if we use hooks in the public API as much.

Regards,
Malcolm


--~--~-~--~~~---~--~~
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: Design Decision: Dynamic settings.SITE_ID (ref. #4438)

[Malcolm Tredinnick]

On Thu, 2007-06-07 at 20:42 -0400, Marty Alchin wrote:
> On 6/7/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > No dbsettings depend on SITE_ID, as far as I can see.
> 
> The most recent version takes the current Site into account, using a
> ForeignKey to contrib.sites.models.Site. It then uses
> Site.objects.get_current() to get the Site for its queries, and as far
> as I can tell from its code, get_current() uses settings.SITE_ID to
> retrieve that object.

Oh, sorry, you mean dbsettings, the third-party app, not as an
abbreviation and typo for database settings (internally in Django). My
error.

> 
> I do realize this wouldn't have any impact on the other Django-proper
> settings. But even just changing this one setting would (likely) have
> a substantial impact on dbsettings. But, since I haven't actually
> tried it, I may well be missing something.

Read the rest of the thread to see how we were discussing doing this.

I think it (dynamic site handling) is something that might have to
happen in one way or another at some point, so it might be worth
thinking about how you can handle it one day maybe. A hash table mapping
site value to the collection of settings, for example. If we ever make
SITE_ID's equivalent dynamic, it would have to be very low-cost to get
the current value anyway, so the extra hash de-reference wouldn't kill
performance in that case. Is that impossible?

Regards,
Malcolm




--~--~-~--~~~---~--~~
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: Send 'text/html' send_mass_mail

[Russell Keith-Magee]

On 6/8/07, Marinho Brandao <[EMAIL PROTECTED]> wrote:
>
> Hello all,
>
> I have notice some users (like me) need for 'text/html' mime-type in
> sendmail (and send_mass_mail, of course), some tickets treats this
> subject.

This is the subject of ticket #3605; it has been discussed a few
times, but there has been some argument as to whether this should be
included. Search the archives for the discussions.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Ping: Extend "for" tag to allow unpacking of lists

[Michael Trier]

This looks really cool.  Thanks SmileyChris.

Michael

On 6/7/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 6/7/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> > On 6/7/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > > Unless there are any objections, I'm happy to check this into trunk.
> >
> > Meh, I'm barely +0, but don't let my apathy stop you :)
>
> +0 from me, too. Go for it, if you'd like.
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.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-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: multiple-db-support

[Russell Keith-Magee]

On 6/8/07, Ben Ford <[EMAIL PROTECTED]> wrote:
> Russ,
>
> Can I suggest doing it the other way round in this case. I believe that the
> multiple-db-support branch has only a small user base and I haven't had time
> to properly test all aspects of the merge, I think it might make it easier
> for others to test if they can just svn up. There are some aspects of the
> branch that still need work and I think that most people who are using it
> recognize this. Also as Carole has expressed an interest in contributing and
> also SVK, it would be beneficial to her (and any others) to be able to grab
> a local copy of the branch which she can keep in source control as she adds
> bits to it.

I appreciate your enthusiasm, and I understand the desire to have a
SVN checkout.

However, we (the core devs) need to set a minimal set of requirements
before we hand out SVN logins. We have, in the past, given out branch
logins to anyone that wanted them. This has, almost without exception,
lead to stale branches as the developer involved loses interest, etc.
A stale branch is worse than no branch at all, because it raises false
expectations, and doesn't reflect well on Django as a whole.

We also have the problem of making sure that the job is going to be
done properly. The ultimate goal will be to merge the branch back into
trunk. However, this isn't going to happen if the branch doesn't meet
Django's coding standard. I'm not just talking about indentation and
spacing here - I mean the technical quality of the code.

Prove to us you can do the work, and that you're not going to lose
interest, and we'll get you a checkout. In the interim, patch -p0 <
mychanges.diff isn't that hard to do; and I would suggest that the
people that can't work out how to use patch probably won't be able to
make a very big contribution to debugging the branch, either.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Newforms-admin question: radio_admin should move?

[Malcolm Tredinnick]

Adrian,

You've mentioned a couple of times that edit_inline support is the
main/only thing missing from newforms-admin now.

I was hoping we could take the chance to also kick radio_admin out of
Field attributes and into ModelAdmin. It's purely presentational and we
can treat it like prepopulate_from now is: a tuple of field names to
which to apply the function.

I'm happy to write the code if you want to do this, but wanted to raise
it so that we decide before the newforms-admin merge.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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: Send 'text/html' send_mass_mail

[Malcolm Tredinnick]

On Fri, 2007-06-08 at 09:08 +0800, Russell Keith-Magee wrote:
> On 6/8/07, Marinho Brandao <[EMAIL PROTECTED]> wrote:
> >
> > Hello all,
> >
> > I have notice some users (like me) need for 'text/html' mime-type in
> > sendmail (and send_mass_mail, of course), some tickets treats this
> > subject.
> 
> This is the subject of ticket #3605; it has been discussed a few
> times, but there has been some argument as to whether this should be
> included. Search the archives for the discussions.

I started ploughing through all the email tickets a while back and then
switched to unicode work, but I should get back to them. I got about
halfway through all of them, from memory.

Reading the notes I made about the earlier discussions, there was no
strong consensus on this item and I was going to add easier support for
multipart messages and then close #3605 because that would provide a way
to send HTML email whilst also encouraging best practice (including a
plain text version).

Anybody who doesn't want that exact behaviour will, of course, still be
able to send their email using Python's direct support or by overriding
the EmailMessage class. Gary Wilson's work to make the mail support more
object-oriented really helps cases like that: we avoid having to cater
to every use-case by making ourselves more extensible.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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: multiple-db-support

[Ben Ford]

Hi Russ,
Thanks for the reply. What's the prescribed way to track multiple patches in
one working copy? I haven't had much experience with patches, but I built my
django base code using patches from a couple of different branch into one
working copy and it caused me problems in that i couldn't then "svn revert"
any of those changes individually...

I completely understand the rationale behind django's svn access policy and
I agree that you can't let just any, unproven person in... With this in mind
and given the fact that I think some kind of SCM is important if more than a
couple of people are working on the branch, I wonder what you and other core
devs would think of this idea:

I could mirror the branch using svk onto my server. Anyone who is interested
in working on it, sharing ideas (or checking on progress) could then have
access to their own copy with the ability to commit changes. It would also
be easy to keep trunk merged into this repo, even though it is remote. When
the code is felt ready to check back into the django branch, svk has a
mechanism to do that, and as a bonus it can also do it incrementally, so
that for each change made on the remote repo there will be a log entry into
the django repo. At any point along the way core devs would be able to check
on progress/code quality etc and make any suggestions.

I have no interest whatsoever in forking django or in any kind of conflict,
I suggest this merely as a possibility for consideration. I think it might
be a fairly elegant way to solve some problems, and would be interested in
getting some feedback...

Thanks,
Ben

On 08/06/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
>
> On 6/8/07, Ben Ford <[EMAIL PROTECTED]> wrote:
> > Russ,
> >
> > Can I suggest doing it the other way round in this case. I believe that
> the
> > multiple-db-support branch has only a small user base and I haven't had
> time
> > to properly test all aspects of the merge, I think it might make it
> easier
> > for others to test if they can just svn up. There are some aspects of
> the
> > branch that still need work and I think that most people who are using
> it
> > recognize this. Also as Carole has expressed an interest in contributing
> and
> > also SVK, it would be beneficial to her (and any others) to be able to
> grab
> > a local copy of the branch which she can keep in source control as she
> adds
> > bits to it.
>
> I appreciate your enthusiasm, and I understand the desire to have a
> SVN checkout.
>
> However, we (the core devs) need to set a minimal set of requirements
> before we hand out SVN logins. We have, in the past, given out branch
> logins to anyone that wanted them. This has, almost without exception,
> lead to stale branches as the developer involved loses interest, etc.
> A stale branch is worse than no branch at all, because it raises false
> expectations, and doesn't reflect well on Django as a whole.
>
> We also have the problem of making sure that the job is going to be
> done properly. The ultimate goal will be to merge the branch back into
> trunk. However, this isn't going to happen if the branch doesn't meet
> Django's coding standard. I'm not just talking about indentation and
> spacing here - I mean the technical quality of the code.
>
> Prove to us you can do the work, and that you're not going to lose
> interest, and we'll get you a checkout. In the interim, patch -p0 <
> mychanges.diff isn't that hard to do; and I would suggest that the
> people that can't work out how to use patch probably won't be able to
> make a very big contribution to debugging the branch, either.
>
> Yours,
> Russ Magee %-)
>
> >
>


-- 
Regards,
Ben Ford
[EMAIL PROTECTED]
+628111880346

--~--~-~--~~~---~--~~
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: multiple-db-support

[SmileyChris]

On Jun 8, 12:58 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> We have, in the past, given out branch
> logins to anyone that wanted them. This has, almost without exception,
> lead to stale branches as the developer involved loses interest, etc.

To true - there is an on-going joke on IRC that being given a Django
branch is equivalent to sailing into the Bermuda Triangle.


--~--~-~--~~~---~--~~
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: Ping: Extend "for" tag to allow unpacking of lists

[SmileyChris]

On Jun 8, 12:57 pm, "Michael Trier" <[EMAIL PROTECTED]> wrote:
> This looks really cool.  Thanks SmileyChris.

And Honza for the initial work on this ticket :)


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

Re: Proposal: Let session support backends

[Faulkner]

Although I personally use memcached for other purposes I wouldn't use
it for session data. Unlike others in the list I need to make sure
session data is persistent and wont get nuked if something crashes.
(well, within reason).

Either way, if we were able to get a pluggable backend up and running
then people can just do what they like.

I was thinking about just reimplementing SessionWrapper to do what I
want, but if there is a chance things will change, well I might hold
off ( or contribute)

Ken


On Jun 7, 9:42 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On 6/6/07, Faulkner <[EMAIL PROTECTED]> wrote:
>
> > Anyone seriously considering making a framework for this?
>
> I, for one, would be all for a (drop-in, API-compatible)sessionlayer
> replacement with pluggable backends. Memcached sessions are a Good
> Idea.
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Design Decision: Dynamic settings.SITE_ID (ref. #4438)

[Marty Alchin]

On 6/7/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Oh, sorry, you mean dbsettings, the third-party app, not as an
> abbreviation and typo for database settings (internally in Django). My
> error.

Ah! Yes, that's understandable. I've been calling it django-values for
so long, the name "dbsettings" seems strange to me, too. We'll all get
used to it sooner or later.

> Read the rest of the thread to see how we were discussing doing this.

Wow, I see your point. I had given it a cursory look, but hadn't
really read through it all.

> I think it (dynamic site handling) is something that might have to
> happen in one way or another at some point, so it might be worth
> thinking about how you can handle it one day maybe. A hash table mapping
> site value to the collection of settings, for example. If we ever make
> SITE_ID's equivalent dynamic, it would have to be very low-cost to get
> the current value anyway, so the extra hash de-reference wouldn't kill
> performance in that case. Is that impossible?

It's absolutely possible, and it wouldn't really add that much extra
to it. As you say, it'd just be an extra hash lookup, after all. As
long as there's a standard way to go about it, I'm on board with
making sure dbsettings lines up with it.

-Gul

--~--~-~--~~~---~--~~
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: multiple-db-support

[Russell Keith-Magee]

On 6/8/07, Ben Ford <[EMAIL PROTECTED]> wrote:
> Hi Russ,
> Thanks for the reply. What's the prescribed way to track multiple patches in
> one working copy? I haven't had much experience with patches, but I built my
> django base code using patches from a couple of different branch into one
> working copy and it caused me problems in that i couldn't then "svn revert"
> any of those changes individually...

There isn't anything prescribed; feel free to use whatever works for
you. There are any number of patch management tools out there that
could make your life easier.

> I have no interest whatsoever in forking django or in any kind of conflict,
> I suggest this merely as a possibility for consideration. I think it might
> be a fairly elegant way to solve some problems, and would be interested in
> getting some feedback...

If you feel enthused enough to set up a SVK repository, feel free, but
the first task that is required is updating the branch to follow the
latest changes in trunk. This isn't really a task that can be
effectively shared amongst many developers so I'm not sure that an SVK
repository will help.

However, providing a series of patches that bring the a stale branch
up to date (and multi-db is _quite_stale) is one very convincing way
to demonstrate that you are serious and capable. Combine that with one
or two non-trivial additional bugfixes, and you will have met the
criteria for getting SVN access.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: multiple-db-support

[Ben Ford]

Hi,
The branch is now up to date as of 5371 (from 4188, yes _stale_ is one word
you could use) in my local svk repo. Some of the tests are failing, (but
they're also failing at the same point when I run the tests in trunk too, so
I'm not quite sure what's going on!!). As for bug fixes I have my eye on
3642  and
3885.
Both of these refer to ForeignKeys breaking down at the point where the
relation crosses from one db to another. I think this is a worthy feature as
i guess the whole point of integrating other db's into your django app is to
interace with existing objects. I'm thinking of another kind of Field
(perhaps OtherDBForeignKey) and Descriptor objects to solve this... Also off
the top of my head i would imagine django.db.models.query will need some TLC
to make it work too!!
Ben

On 08/06/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
>
> On 6/8/07, Ben Ford <[EMAIL PROTECTED]> wrote:
> > Hi Russ,
> > Thanks for the reply. What's the prescribed way to track multiple
> patches in
> > one working copy? I haven't had much experience with patches, but I
> built my
> > django base code using patches from a couple of different branch into
> one
> > working copy and it caused me problems in that i couldn't then "svn
> revert"
> > any of those changes individually...
>
> There isn't anything prescribed; feel free to use whatever works for
> you. There are any number of patch management tools out there that
> could make your life easier.
>
> > I have no interest whatsoever in forking django or in any kind of
> conflict,
> > I suggest this merely as a possibility for consideration. I think it
> might
> > be a fairly elegant way to solve some problems, and would be interested
> in
> > getting some feedback...
>
> If you feel enthused enough to set up a SVK repository, feel free, but
> the first task that is required is updating the branch to follow the
> latest changes in trunk. This isn't really a task that can be
> effectively shared amongst many developers so I'm not sure that an SVK
> repository will help.
>
> However, providing a series of patches that bring the a stale branch
> up to date (and multi-db is _quite_stale) is one very convincing way
> to demonstrate that you are serious and capable. Combine that with one
> or two non-trivial additional bugfixes, and you will have met the
> criteria for getting SVN access.
>
> Yours,
> Russ Magee %-)
>
> >
>


-- 
Regards,
Ben Ford
[EMAIL PROTECTED]
+628111880346

--~--~-~--~~~---~--~~
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: multiple-db-support

[Russell Keith-Magee]

On 6/8/07, Ben Ford <[EMAIL PROTECTED]> wrote:
> Hi,
> The branch is now up to date as of 5371 (from 4188, yes _stale_ is one word
> you could use) in my local svk repo. Some of the tests are failing, (but
> they're also failing at the same point when I run the tests in trunk too, so
> I'm not quite sure what's going on!!).

Which tests?

Are you running MySQL? There are some known test failures due to
problems in the way MySQL handles row-level integrity.

> As for bug fixes I have my eye on
> 3642 and 3885. Both of these refer to ForeignKeys breaking down at the point
> where the relation crosses from one db to another. I think this is a worthy
> feature as i guess the whole point of integrating other db's into your
> django app is to interace with existing objects.

Agreed.

> I'm thinking of another
> kind of Field (perhaps OtherDBForeignKey) and Descriptor objects to solve
> this...

Hrm... my gut reaction is that the model description shouldn't know it
is separated across databases; this is a deployment issue, so it
wouldn't be good to hard code deployment into the model.

> Also off the top of my head i would imagine django.db.models.query
> will need some TLC to make it work too!!

The queryset is (hopefully) about to undergo a bit of a refactor; so:

1) Don't base too much of your changes on massive reworkings of query.py
2) If you come across any refactorings that would be useful -
especially in relation to writing custom fields, etc - make sure you
make them known.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: multiple-db-support

[Ben Ford]

Which tests?

modeltests/test_client/ClientTest.test_session_modifying_view returns ok and
after that everything stops... I have to kill the bash session.

>Are you running MySQL? There are some known test failures due to
>problems in the way MySQL handles row-level integrity.

One of my databases is MySQL, but the tests are all running on Postgres

>Hrm... my gut reaction is that the model description shouldn't know it
>is separated across databases; this is a deployment issue, so it
>wouldn't be good to hard code deployment into the model.

That's my feeling as well. I'm trying to keep my mitts off the existing code
as much as possible though, I guess one other option would be a property on
ForeignKey that it could set on initialization by looking at it's
rel.to._default_manager.connection  and making sure it's the same as the
class the FK is defined on?

>The queryset is (hopefully) about to undergo a bit of a refactor; so:
>
>1) Don't base too much of your changes on massive reworkings of query.py
>2) If you come across any refactorings that would be useful -
>especially in relation to writing custom fields, etc - make sure you
>make them known.

The parts I have in mind that would most need to change are probably
lookup_inner. I'll be looking to intercept the query at the point where a __
indicates a change of database and construct a select that looks more like
this:
  SELECT [columns,] from first_table where pk in (list_of_pk_values)
The list_of_pk_values will have to be generated by running the part of the
query after the __ in a separate query on the related database.

So these classes:
class ThisDBModel(models.model):


class OtherDBModel(models.model):

lookup_field = models.CharField(..)
firstdb_class = models.ForeignKey(ThisDBModel, related_name='otherfk')


And this query;
ThisDBModel.objects.filter(otherfk__lookup_field='whatever')

Would end up as:
  list_of_fk_values = SELECT firstdb_class_id FROM otherdbmodel WHERE
lookup_field = 'whatever';  #run on the other db
and:
  final_query =  SELECT * from thisdbmodel WHERE pk_column in
(list_of_fk_values);  #run on the main db

What do you think?

-- 
Regards,
Ben Ford
[EMAIL PROTECTED]
+628111880346

--~--~-~--~~~---~--~~
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: multiple-db-support

[Russell Keith-Magee]

On 6/8/07, Ben Ford <[EMAIL PROTECTED]> wrote:
>
> Which tests?
>
> modeltests/test_client/ClientTest.test_session_modifying_view
> returns ok and after that everything stops... I have to kill the bash
> session.

!?!

Sorry, no ideas. Can you isolate the test that is failing by running
the tests individually, rather than as a complete suite?

> >Hrm... my gut reaction is that the model description shouldn't know it
> >is separated across databases; this is a deployment issue, so it
> >wouldn't be good to hard code deployment into the model.
>
> That's my feeling as well. I'm trying to keep my mitts off the existing code
> as much as possible though, I guess one other option would be a property on
> ForeignKey that it could set on initialization by looking at it's
> rel.to._default_manager.connection  and making sure it's
> the same as the class the FK is defined on?

The Model should probably be keeping track of the database it is on,
rather than the field. The model base already tracks column names and
the like; adding a database name wouldn't be out of place. Then, if a
field references a model, you can compare the remote model's database
name with the local model.

> Would end up as:
>   list_of_fk_values = SELECT firstdb_class_id FROM otherdbmodel WHERE
> lookup_field = 'whatever';  #run on the other db
> and:
>   final_query =  SELECT * from thisdbmodel WHERE pk_column in
> (list_of_fk_values);  #run on the main db

Sounds about right. The devil is in the detail, though.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: multiple-db-support

[Ben Ford]

>The Model should probably be keeping track of the database it is on,
>rather than the field. The model base already tracks column names and
>the like; adding a database name wouldn't be out of place. Then, if a
>field references a model, you can compare the remote model's database
>name with the local model.


Essentially, that's what this bit is doing:
   rel.to._default_manager.connection
In muti-db the model's default manager keeps a reference to the db.

I'll see if i can  have a play with the tests and nail it down a bit
better!
Ben


-- 
Regards,
Ben Ford
[EMAIL PROTECTED]
+628111880346

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