Re: ticket 13125 is waiting for a design decision for 18 months

[subs...@gmail.com]

Could anyone provide a use case where I want a de-activated user to
remain authenticated? Who is this option for? Why is it default?

When I originally reported this ticket I did so because this is a
plain security risk--non-technical users uncheck 'is active' when they
want to lock someone out of access. They don't realize that the
session remains active and I believe this to be an oversight within
the original design, not a design preference.

On Sep 8, 2:11 am, Vladimir Kryachko  wrote:
> I think it has been done on purpose, and should not be changed.
> Because different authentication backends may choose to support
> inactive users or not. And the default (ModelBackend) supports
> inactive users which is expressed in
> ModelBackend.supports_inactive_user = True. So I would suggest you
> write a custom decorator.
>
>
>
>
>
>
>
> On Fri, Sep 2, 2011 at 6:49 AM, Wim Feijen  wrote:
> > I'd like to draw attention to an open ticket which needs a design
> > decision.
>
> > Description:
> > "The login_required decorator is not checking User.is_active, as
> > staff_member_required does. If an authenticated user is deactivated
> > (via setting is_active to False), the user is still able to browse
> > login_required-protected views."
>
> > For probably most people, the expected and (most likely) wanted
> > behavior would be not to let inactive users have access to
> > login_required files.
>
> > Wim
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

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

Re: Possible bug with DATABASE_ROUTERS?

[subs...@gmail.com]

I found I had another router that was being greedy.

On Apr 8, 12:15 pm, "subs...@gmail.com" <subs...@gmail.com> wrote:
> Hello everyone,
>
> I posted to the user's list but haven't heard anything. I am wondering
> if this sounds like it could potentially be a bug:
>
> http://groups.google.com/group/django-users/browse_thread/thread/253b...
>
> if this is due to my misunderstanding of routers, please forgive my
> posting here (but if you choose to grace me with a reply @ -users,
> thank you).
>
> -Steve

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

Possible bug with DATABASE_ROUTERS?

[subs...@gmail.com]

Hello everyone,

I posted to the user's list but haven't heard anything. I am wondering
if this sounds like it could potentially be a bug:

http://groups.google.com/group/django-users/browse_thread/thread/253b77110fb68a89

if this is due to my misunderstanding of routers, please forgive my
posting here (but if you choose to grace me with a reply @ -users,
thank you).

-Steve

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

Re: Could the comments framework be more generic?

[subs...@gmail.com]

Heh, already put a few hours doing something like this. There's some
django-discus attempts out there--have you looked at them? I haven't
bothered to notice if any use the comments framework but it sure would
be handy to make comments out of discus or backtype feeds or variants
thereof.

But whether it was in trunk or just somewhere on github, I'd use it
either way. In my thinking about doing this I never really ran into a
compatibility/patch issue. Did you?

-Steve

On Nov 27, 6:55 pm, Kevin Renskers  wrote:
> Hi,
>
> I'd like to make a suggestion about the build in comments framework.
> Right now, even though you can write your own extension to the
> comments framework, it is always tied to database models. I am trying
> to build an extension that uses the API offered by Disqus, meaning I
> don't want to use the local database to do a count of comments, get
> the list of comments, etc.
>
> If Django's comments framework would offer an API that is one level
> above the database models, we could write our own functions that
> implement getting comments, saving them, do a count of comments for
> the object, etc.
>
> I understand that a logical reaction to this suggestion would be to
> just not use Django's comments app, but roll my own. But I want to
> integrate the Disqus comments with existing apps, that already use
> Django's system to, for example, show the count of comments on blog
> articles in the admin interface. Django-blog-zinnia does this.
>
> I am looking forward to any comments and ideas. Is something like this
> even possible without completely breaking backwards compatibility?
>
> Kind regard,
> Kevin Renskers

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

Did you know deleting an inline doesn't warn you about cascading deletes?

[subs...@gmail.com]

Neither did I until today. It is understandable that from a use-case
perspective, inlines look less like 'Deletes' and more like
'Disassociates' (from the admin model). Janet thought so in the office
when she nuked a few years worth of survey data, and I think its a
rather blameless mistake. Nevermind that, we already agree the
cascading delete warning is a good thing.

Apparently the form-checkbox nature of the delete button makes form-
save and cascade delete warn very tricky.

Filed a ticket: http://code.djangoproject.com/ticket/14411

A far less tricky situation would be to turn the delete from a form
element into a button and give the usual cascading delete warning.
carljm pointed out at the ticket discussion that this is "an
alternative that's just as bad". I can hardly agree that a potentially
cleared form (but probably not, with modern browsers), is anywhere
near equal to an accidentally cleansed table. One seems orders worse,
but perspectives vary I guess. And if that's really a horror we can't
bear, there's always a javascript warning.

Got squashed prematurely IMHO. There several better ways we could
treat these situations and prompt for cascading deletes.

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

Re: rethinking raw_id_fields

[subs...@gmail.com]

Righton. I haven't used it too intensely for filtering and sorting but
I do have some other thoughts about that.

1) Would it be better to come up with a non-changelist changelist for
raw_id_fields. I find myself avoiding raw_id_fields because I don't
necessarily want to register the object in question in the admin and
give change permissions. Also, the current resulting pop-up of a
changelist window is very displeasing to me and seems really just kind
of hacked together. Having the actions dropdown among other things
confuses things. I guess in this case one couldn't avoid registering
it in admin (or could we, and provide a default which uses the
unicode?).

2) Does anyone think there would be any advantage to 'flatten'
raw_id_fields? Essentially, it would become a non-javascript link that
would bring up a changelist which leads us back to the original
changelist and autopopulates it? Screen-reading software is rather
ambiguous when it comes to the current usability flow (aka I have had
user complaints). The problem is pretty well outlined here:
http://webaim.org/techniques/javascript/other#popups (I autocompleted
on google to find that :).

-Steve

On Oct 4, 9:56 am, Chuck Harmston <ch...@chuckharmston.com> wrote:
> We're playing semantic leapfrog here, but I don't see the proposed Ajax
> solution as "searching", I see it as "autocompleting"; people won't use it
> to discover content, they will use it as a shortcut for accessing content
> that they are familiar with. As I said, much of the utility of the
> raw_id_fields popup is that it allows content discovery, which is an
> important use case—not all admin users will be perfectly familiar with the
> content.
>
> I am in full favor of an Ajax autocomplete widget (which, as I said, already
> exists in the admin-ui branch), but do not want it to replace raw_id_fields;
> their uses cases are completely disparate.
>
> On Mon, Oct 4, 2010 at 12:05 AM, subs...@gmail.com <subs...@gmail.com>wrote:
>
>
>
>
>
> > With the AJAX field implementation on the table you're free to
> > represent the objects however you want. Yeah, there's a few things
> > left out but did you really say 'no searching'?
>
> > -Steve
>
> > On Oct 3, 10:09 pm, Chuck Harmston <ch...@chuckharmston.com> wrote:
> > > it's based on the assumption that the user knows the value of the unicode
> > > representation of the object. It does not allow for discovery like the
> > > raw_id_fields popup does: no filtering, no sorting, no searching, and no
> > > browsing. I am a strong -1 this.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com<django-developers%2Bunsubscr 
> > i...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> --
> *
> Chuck Harmston
> *
> ch...@chuckharmston.comhttp://chuckharmston.com

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

Re: rethinking raw_id_fields

[subs...@gmail.com]

With the AJAX field implementation on the table you're free to
represent the objects however you want. Yeah, there's a few things
left out but did you really say 'no searching'?

-Steve

On Oct 3, 10:09 pm, Chuck Harmston  wrote:
> it's based on the assumption that the user knows the value of the unicode
> representation of the object. It does not allow for discovery like the
> raw_id_fields popup does: no filtering, no sorting, no searching, and no
> browsing. I am a strong -1 this.

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

Re: rethinking raw_id_fields

[subs...@gmail.com]

Does anyone besides me think that an AJAX field admin solution
effectively deprecates raw_id_fields?

I'm interested in seeing a ticket like #14370 go forward if only to
close a slew of dusty old tickets about raw_id_fields.

-Steve

On Oct 3, 5:58 am, Marcob  wrote:
> Well, M2M and raw_id_fields are a big player in wonderful admin
> contrib with a poor interface: why do not improve them?

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

Re: rethinking raw_id_fields

[subs...@gmail.com]

Edit. Edit.

"I just don't think making an absolute answer to that discussion a
contingency to this called-for feature /is a good idea/".

There we go.

On Oct 1, 11:19 am, "subs...@gmail.com" <subs...@gmail.com> wrote:
> Please don't think I'm trying to hinder discussion. I just don't think
> making an absolute answer to that discussion a contingency of this
> called-for feature.

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

Re: rethinking raw_id_fields

[subs...@gmail.com]

And then it was so:

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

On Sep 30, 3:54 pm, "subs...@gmail.com" <subs...@gmail.com> wrote:
> Yeah, I think your right. raw_id_fields is a neat idea if you really
> are reluctant to use AJAX. If introducing AJAX into admin is fine,
> dumping these fields altogether seems the best approach.
>
> As for the options given, I've only used ajax-selects. I think its
> implementation is rather cumbersome in situations where I didn't
> really care about what the resulting list looked like (if I just
> wanted a list of the objects represented by whatever is in their
> __unicode__).
>
> So a starting admin equivalent might look like: ajax_fields =
> {'person': ['first_name','last_name']}. The list in this case is the
> search_fields which kind of mirrors admin's current functionality. Or
> maybe I'm getting ahead of myself.
>
> -Steve
>
> On Sep 30, 2:21 pm, "burc...@gmail.com" <burc...@gmail.com> wrote:
>
>
>
> > On Thu, Sep 30, 2010 at 10:27 PM, subs...@gmail.com <subs...@gmail.com> 
> > wrote:
> > > At that point its not really raw_id_fields, is it? =)
>
> > After all, what's the purpose of these fields?
>
> > --
> > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> > MSN: bu...@live.com

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

Re: rethinking raw_id_fields

[subs...@gmail.com]

Yeah, I think your right. raw_id_fields is a neat idea if you really
are reluctant to use AJAX. If introducing AJAX into admin is fine,
dumping these fields altogether seems the best approach.

As for the options given, I've only used ajax-selects. I think its
implementation is rather cumbersome in situations where I didn't
really care about what the resulting list looked like (if I just
wanted a list of the objects represented by whatever is in their
__unicode__).

So a starting admin equivalent might look like: ajax_fields =
{'person': ['first_name','last_name']}. The list in this case is the
search_fields which kind of mirrors admin's current functionality. Or
maybe I'm getting ahead of myself.

-Steve

On Sep 30, 2:21 pm, "burc...@gmail.com" <burc...@gmail.com> wrote:
> On Thu, Sep 30, 2010 at 10:27 PM, subs...@gmail.com <subs...@gmail.com> wrote:
> > At that point its not really raw_id_fields, is it? =)
>
> After all, what's the purpose of these fields?
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: bu...@live.com

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

Re: rethinking raw_id_fields

[subs...@gmail.com]

At that point its not really raw_id_fields, is it? =)

-Steve

On Sep 30, 3:07 am, "burc...@gmail.com" <burc...@gmail.com> wrote:
> Hi Subsume,
>
> why not just replace them with some proper implementation of ajax completion ?
>
> http://djangopackages.com/grids/g/auto-complete/
>
> On Thu, Sep 30, 2010 at 12:34 PM, subs...@gmail.com <subs...@gmail.com> wrote:
> > Hello all,
>
> > I was browsing the tickets and saw a few of them nagging about some
> > restrictions to raw_id_fields. That they are limited to other objects
> > registered in admin, that they are limited arbitrarily (relative to a
> > regular FK) by the permissions of the user, etc. Personally, I find
> > the little changelist window that pops up a bit awkward and hackish-
> > looking.
>
> > Might a better approach be to have a django-admin view which uses
> > content-types to generate a list of the objects in question? If
> > someone can give me a simple yes, no, etc, I'd be willing to do the
> > necessary ticket-work and come up with a patch for review.
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: bu...@live.com

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

rethinking raw_id_fields

[subs...@gmail.com]

Hello all,

I was browsing the tickets and saw a few of them nagging about some
restrictions to raw_id_fields. That they are limited to other objects
registered in admin, that they are limited arbitrarily (relative to a
regular FK) by the permissions of the user, etc. Personally, I find
the little changelist window that pops up a bit awkward and hackish-
looking.

Might a better approach be to have a django-admin view which uses
content-types to generate a list of the objects in question? If
someone can give me a simple yes, no, etc, I'd be willing to do the
necessary ticket-work and come up with a patch for review.

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

Re: A few thoughts on Process 2 cents

[subs...@gmail.com]

Sorry about that. I was actually kind of interested in whether the
'process' aspect of admin (and possibly other contrib apps?) had
undergone any changes, given that I've heard some sentiment about
people hoping contrib was 'approaching zero'.

-Steve

On Sep 29, 4:39 pm, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Wed, Sep 29, 2010 at 3:21 PM, subs...@gmail.com <subs...@gmail.com> wrote:
> > Speaking of which... who is interested in admin these days? Been
> > trying to scare up some feedback @http://code.djangoproject.com/ticket/5833
> > for some time now.
>
> Please don't derail threads with unrelated topics like this. It makes
> discussions really hard to follow. Thanks.
>
> Jacob

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

Re: A few thoughts on Process 2 cents

[subs...@gmail.com]

Speaking of which... who is interested in admin these days? Been
trying to scare up some feedback @ http://code.djangoproject.com/ticket/5833
for some time now.

On Sep 29, 2:39 pm, Jacob Kaplan-Moss  wrote:
> sense to have more area-specific committers. If someone's well-versed
> in the admin, a lack of interest in the ORM certainly shouldn't be an

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

Re: Class based models

[subs...@gmail.com]

Hmm... I do see what you're saying.

The line in question, however, should respect subclasses. So your
example wouldn't fail in the case of a proper subclass.

I checked out that thread and I saw Russel commented on it and
ironically he mentioned contrib.comments as well.

One thing you say is 'providing abstract models feels really awkward'--
Why?

It seems like you almost want an 'attributes_for' option in the model
Meta options whereby one model can stand-in for another model. Still,
a lot of your proposal seems to rely on a developer's 'best
practices'--aka something akin to contrib.comments' get_model() use in
views and form (which can't be codified with patches, really).

-Steve

PS: One nag I have about get_model() is that is singular. Sure,
contrib.comments happens to only have one extensible but what about
when there's more?

On Sep 27, 5:45 pm, Klaas van Schelven <klaasvanschel...@gmail.com>
wrote:
> There's a quite a few things that I don't like about the get_model
> approach. I'll focus on one though: contrib.comment's own models do
> not respect it.
>
> Consider a customized model for comments (the model MyComment in
> my_comments)
> so in settings.py we put:
> COMMENTS_APP = 'my_comments'
>
> then we do the following:
> from django.contrib.comments.models import CommentFlag
> flag = CommentFlag()
> from django.contrib.comments import get_model
> mycomment = get_model().objects.get()
> flag.comment = mycomment
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "...django/db/models/fields/related.py", line 318, in __set__
>     self.field.name, self.field.rel.to._meta.object_name))
> ValueError: Cannot assign "":
> "CommentFlag.comment" must be a "Comment" instance.
>
> You see the problem? Any help thinking about the solution is much
> appreciated.
>
> Klaas
>
> On Sep 27, 7:57 pm, "subs...@gmail.com" <subs...@gmail.com> wrote:
>
>
>
> > I thought that's what get_model did?
>
> > You specify your own comments app and register your own (subclass or
> > other) model within that function and its used throughout the original
> > app.
>
> > On Sep 27, 3:02 am, Klaas van Schelven <klaasvanschel...@gmail.com>
> > wrote:
>
> > > On Sep 27, 4:17 am, "subs...@gmail.com" <subs...@gmail.com> wrote:
>
> > > > I may be dense but is this the functional equiv of cobtrib.comments
> > > > get_model()?
>
> > > Nope.
> > > Rather, it's a way to subclass models that are provided by reusable
> > > apps, and letting the reusable app use the subclassed instance
> > > throughout.
>
> > > > On Sep 26, 8:28 am, Klaas van Schelven <klaasvanschel...@gmail.com>
> > > > wrote:
>
> > > > > Hi all,
>
> > > > > I'm looking for a bit of input for making Django's apps a bit more
> > > > > extendable, either by modifying Django or (preferably) by coming up
> > > > > with a common language on top op Django. The main painpoint are
> > > > > extendable models. The idea of 'extendable' is that models from
> > > > > reusable apps can be extended in any concrete project. The reusable
> > > > > apps should refer to their own models in such a way that they will get
> > > > > the concrete implementation (extension).
> > > > > Class based models if you will.
>
> > > > > Context can be found 
> > > > > here:http://groups.google.com/group/django-users/browse_thread/thread/2287...
>
> > > > > Currently, apps usually refer to their own models by simply importing
> > > > > them from models.py and referring to them. This obviously will not
> > > > > work, so any solution will need some kind of registry, or instance of
> > > > > "app". If "app" is an instance of a class referring to it can be done
> > > > > in an extendible way (simply by using Python's inheritance mechanism).
>
> > > > > I've put an example of this approach 
> > > > > here:http://bitbucket.org/vanschelven/extendible_app_experiment/src/0862ce...
>
> > > > > Which incorporates the above idea of an app class & instance in blog/
> > > > > __init__.py.
>
> > > > > abstract_blog/abstract_models.py and blog/models.py
>
> > > > > The key sections are:
> > > > > (in abstract_models)
>
> > > > >     def get_AbstractPage(self):
> > > > >         class AbstractPage(models.Model):
> > > > >        

Re: Class based models

[subs...@gmail.com]

I may be dense but is this the functional equiv of cobtrib.comments
get_model()?

On Sep 26, 8:28 am, Klaas van Schelven 
wrote:
> Hi all,
>
> I'm looking for a bit of input for making Django's apps a bit more
> extendable, either by modifying Django or (preferably) by coming up
> with a common language on top op Django. The main painpoint are
> extendable models. The idea of 'extendable' is that models from
> reusable apps can be extended in any concrete project. The reusable
> apps should refer to their own models in such a way that they will get
> the concrete implementation (extension).
> Class based models if you will.
>
> Context can be found 
> here:http://groups.google.com/group/django-users/browse_thread/thread/2287...
>
> Currently, apps usually refer to their own models by simply importing
> them from models.py and referring to them. This obviously will not
> work, so any solution will need some kind of registry, or instance of
> "app". If "app" is an instance of a class referring to it can be done
> in an extendible way (simply by using Python's inheritance mechanism).
>
> I've put an example of this approach 
> here:http://bitbucket.org/vanschelven/extendible_app_experiment/src/0862ce...
>
> Which incorporates the above idea of an app class & instance in blog/
> __init__.py.
>
> abstract_blog/abstract_models.py and blog/models.py
>
> The key sections are:
> (in abstract_models)
>
>     def get_AbstractPage(self):
>         class AbstractPage(models.Model):
>             body = models.TextField()
>             category = models.ForeignKey(self.app.models.Category)
>
>             class Meta:
>                 abstract = True
>                 #app_label = 'abstract_blog'
>         return AbstractPage
>     AbstractPage = property(get_AbstractPage)
>
> (in models)
>     def get_Category(self):
>         class Category(self.AbstractCategory):
>             some_added_field = models.IntegerField()
>         return Category
>     Category = property(get_Category)
>
> As you can see, it is possible to refer to "the apps real
> implementation of Category" (self.app.models.Category, or just
> self.Category) from the abstract model. Less neat: the cruft that's
> needed to pass self into AbstractPage for reference (3 lines per
> class: def, return & property).
>
> In a more recent version I've managed to factor those lines away at
> the cost of a lot of 
> magic.http://bitbucket.org/vanschelven/extendible_app_experiment/src/2b8eb6...
>
> class AbstractModels(object):
>     #...
>     class AbstractPage(shmodels.Model):
>         body = shmodels.TextField()
>         category =
> shmodels.ForeignKey(Zelf("app.models.Category"))
>
> Neet uh? Self referral without an actual introduction of "self".
>
> I may look for the general case of Zelf & Zelf2 and shmodels and
> whatever... but I'd like to know that this is a path worth following.
> In other words: am I missing really obvious, more simple solutions
> here?
>
> ciao,
> Klaas

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

Re: My problem with proposed Custom FilterSpec implementation

[subs...@gmail.com]

Maybe code talks?

I added a patch to http://code.djangoproject.com/ticket/5833 which
sums up the kind of change I am gunning for. If anyone has some
feedback, awesome.

-Steve

On Sep 7, 3:22 pm, "subs...@gmail.com" <subs...@gmail.com> wrote:
> Hello there,
>
> I'm watching #5833 and I have a bit of a problem with the
> implementation.  A good example of their proposal is here:
>
> http://code.djangoproject.com/ticket/5833#comment:68
>
> The API is remarkably similar to Gaynor's django-filters. My problem
> with this is that your filtering essentially becomes
> Model.objects.filter(x__y=x).filter(y__x=y) which creates a join each
> time, whereas you may not really want a join.
>
> To get around this limitation I propose having the FilterSpec's return
> Q objects and then passing them all into filter(), however I've been
> stumped as to how to do this in such a way that you allow people to
> use AND or OR, depending on their preference.
>
> I'm afraid if this issue isn't worked out the current proposal (which
> is Accepted) will then become gospel and many uses cases (mine!) will
> be left out.
>
> -Steve

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

My problem with proposed Custom FilterSpec implementation

[subs...@gmail.com]

Hello there,

I'm watching #5833 and I have a bit of a problem with the
implementation.  A good example of their proposal is here:

http://code.djangoproject.com/ticket/5833#comment:68

The API is remarkably similar to Gaynor's django-filters. My problem
with this is that your filtering essentially becomes
Model.objects.filter(x__y=x).filter(y__x=y) which creates a join each
time, whereas you may not really want a join.

To get around this limitation I propose having the FilterSpec's return
Q objects and then passing them all into filter(), however I've been
stumped as to how to do this in such a way that you allow people to
use AND or OR, depending on their preference.

I'm afraid if this issue isn't worked out the current proposal (which
is Accepted) will then become gospel and many uses cases (mine!) will
be left out.

-Steve

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

Re: Template Tag Not Reinitialized in Loop

[subs...@gmail.com]

I recently ran into this problem too for the first time. Essentially
this boils down to my not being able to use a templatetag in a loop in
some cases. What is the simple workaround that I'm missing?

-Steve

On May 5, 2:12 pm, Apreche  wrote:
> I had a really strange bug in one of my custom template tags today. It
> took me the entire morning to figure it out, but I finally did. I'm
> not sure if it's a bug or a feature, but I wanted to make a post to
> help the next person who has this same problem.
>
> Let's pretend you make a custom template tag foo. The render method
> for foo is in a class FooNode, and you pass it a person from the
> context.
>
> {% foo persona %}
> {% foo personb %}
>
> Then, as is common, you have a list of people that you render with a
> loop in the template.
>
> {% for person in people %}
> {% foo person %}
> {% endfor %}
>
> It turns out that when a template tag stands alone, the __init__ of
> FooNode will be called each time the template tag appears. However,
> when the template tag is inside of a loop, the __init__ of the FooNode
> is only called once. That single instance of FooNode sticks around,
> and it's render method is called over and over as the loop goes
> around.
>
> This doesn't seem like that big of a deal. However, my template tag
> was written in such a way that data members of FooNode were being set
> in the __init__ and reused in the render(). Because the initialization
> only happened the first time through the loop, the template tag always
> rendered as if it was for the first person in the list. Those data
> members carried over to subsequent renders because the Node was not
> reinitialized. I managed to fix it, but be aware. If your template
> tags are behaving strangely when they are in loops, this is probably
> the issue.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

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

Re: logialogin_required does not check User.is_active

[subs...@gmail.com]

Could the burden of this work be successfully (and sensibly) shifted
to the backend itself by calling something like... deactivate()?

In this event, the default backend's logic could be 'set is_active =
False and expire cookie' and custom backends could do (or not do)
whatever they want.

Forgive me for the hypothetical responses, as I don't have any
experience with custom backends.

-Steve

On Apr 15, 8:55 pm, Russell Keith-Magee 
wrote:

>  1) Backends aren't required to subclass a common base class, so we
> have to assume that there will be custom backends out there that
> *wont'* have an is_active check, even if we add one to ModelBackend.
> This isn't a huge problem - we can work around it with a hasattr check
> - but it's worth noting as something that will need to be addressed.
>
>  2) How do you get access to the right authentication backend in the
> login_required decorator? The only argument you are guaranteed to have
> access to is user, and the user doesn't (currently) have a way to get
> access to the backend on which they were authenticated.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

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

Re: logialogin_required does not check User.is_active

[subs...@gmail.com]

Thanks for breaking it down.

On Mar 17, 7:45 am, Russell Keith-Magee 
wrote:

>  1) Don't touch the code. It's an annoying edge case, but it can be
> caught by shortening session timeouts and making more use of
> permissions. However, we should document the edge case with
> login_required, as it is certainly contrary to obvious usage.

This isn't appropriate in situations where HR wants to do a hard cut-
off of a user's access, in the event they are terminated.

>  2) Add a specific "requires_active_user" decorator (and maybe a
> decorator that combines the login_required and requires_active_user
> check)

Eh.

>  3) Allow login_required to take an argument that customizes the
> 'active' check. However, the default value for this argument would
> need to be equivalent to the current behaviour; once you start down
> this path, there really isn't much difference between a call to
> login_required with an 'is_active' argument, and a call to
> user_passes_test that does the authentication and active check.

Seems strange: "I want a user to be authenticated to use this view,
but I don't care if they're active." I'm not sure I agree that the
default should be the current behavior. I think in most cases this is
an oversight that most programmers simply don't account for in their
code--and closing this hatch is a favor and not an incompatibility
issue. Could be wrong.

>  4) Work out if there is a way to refactor the login process so that
> the decision of whether is_active is checked is deferred. I don't have
> any great ideas how this could be done, though.

Would it be too ugly or simplistic to have a callable
Backend.is_active() which these backends could manipulate to their
liking? Its flexible in the same way as get_profile(). Also, is it
possible we're expecting too much perfection given that, as you say,
there are legitimate proposals to refactor auth.User either way? (and
present solutions are more or less trivial).

-Steve

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

Re: Security hole with authenticated sessions

[subs...@gmail.com]

Oh, and I apologize for the racy subject line =)

On Apr 15, 10:51 am, "subs...@gmail.com" <subs...@gmail.com> wrote:
> Please note I've already consulted secur...@djangoproject.com about
> this and Jacob told me to post it here if I wanted to.
>
> One problem with authenticated sessions is that, upon de-activation of
> a user's account, any sessions that user has remain live until they
> logout.
>
> I think it would be a good idea to add a middleware to auth which
> checked is_active and, if it was found to be False, redirected the
> user to the logout url. Indeed it may look something like 
> this:http://dpaste.com/184192/
>
> -Steve

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

Security hole with authenticated sessions

[subs...@gmail.com]

Please note I've already consulted secur...@djangoproject.com about
this and Jacob told me to post it here if I wanted to.

One problem with authenticated sessions is that, upon de-activation of
a user's account, any sessions that user has remain live until they
logout.

I think it would be a good idea to add a middleware to auth which
checked is_active and, if it was found to be False, redirected the
user to the logout url. Indeed it may look something like this:
http://dpaste.com/184192/

-Steve

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

Re: Validate a form's excluded fields if a value is present

[subs...@gmail.com]

Seems like a security hole, whereby people may supply additional
fields if they can guess their counterparts on the model. Its
'exclude', not 'exclude_maybe'.

...Unless I'm missing something fundamental.

-S

On Mar 31, 9:11 pm, orokusaki  wrote:
> I'm working on an SAAS project, and there is an ``account`` attribute
> (foreign key) on every model in the project (similar to those who have
> a ``user`` or ``created_by`` attribute on every model). ``account`` is
> added to the request object using a MiddleWare class.
>
> When I'm writing views, I have to do this in each view:
>
>     if request.method == 'POST':
>         form = SomeSpamForm(request.POST)
>         form.instance.account = request.account
>         if form.is_valid():
>             instance = form.save(commit=False)
>             try:
>                 instance.full_clean()
>             except ValidationError, e:
>                 form._update_errors(e.message_dict)
>             else:
>                 instance.save()
>
> I admit that I tend to be a bit OCD about coding style, but I think
> most programmers would agree that doing that in every single view is a
> very bad idea, especially if you ever intend on upgrading Django in
> the future. Imagine having 178 views in 19 apps in a project with that
> same code, and updating every single one. Of course I could write some
> sort of monkey patch and pray, but instead I thought of what might be
> a good solution:
>
> In forms.models.BaseModelForm._get_validation_exclusions() ( Defined
> on line # 266 in SVN) you'll find:
>
> 283                 # Exclude fields that aren't on the form. The
> developer may be
> 284                 # adding these values to the model after form
> validation.
> 285                 if field not in self.fields:
> 286                     exclude.append(f.name)
>
> Couldn't this be changed to:
>
> 283                 # Exclude fields that aren't on the form. The
> developer may be
> 284                 # adding these values to the model after form
> validation.
> 285                 if field not in self.fields and not
> self.cleaned_data.get(field, None):
> 286                     exclude.append(f.name)
>
> This would allow me to do this instead of my above example:
>
>     if request.method == 'POST':
>         form = SomeSpamForm(request.POST)
>         form.instance.account = request.account
>         if form.is_valid():
>             form.save()
>
> That seems way better than manually running validation outside of the
> excellent ``ModelForm`` built-in error handling. I'm not trying to
> brown nose here (OK, I am a little), but ``ModelForm`` is so great to
> use that it's a shame to have the best part (validation) leak into my
> views.

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

Re: Potential bugs / need for extra documentation in 'Customizing the comments framework'

[subs...@gmail.com]

> I can't think of any reason that a production server should behave
> differently to a development server on the sorts of issues you're
> referring to. If there's a problem, I would be highly surprised if
> it's caused by the fact you're running under wsgi, rather than the
> devserver. There may be differences between your production
> environment and your development environment that cause these
> problems, but if you were to reverse the environmental issues, I
> suspect you would find production working fine, but development
> failing.

And yet. I did everything I could to get the missing comments_app
error to pop in dev, but I was unable to mirror the effects in dev.
The two environments are already incredibly simple--one server houses
little else but the project in question.

> > Three things:

> > 1) Its not obvious to me why, but importing a custom comment model as
> > 'Comment' seems, somehow, to get back upstream to

> A bug of this sort really needs a specific example. It's impossible to
> tell from the detail you provide whether this is a legitimate bug, or
> a flaw in your usage (and if it is a flaw in your usage, whether there
> is anything we can do to better report errors).

Agreed. I will munge around more and see if I can't come up with
that.

> > 3) Models hoping to foreignkey to whatever comments model the app
> I'm not sure what you're saying here. Are you complaining about the
> way that we've implemented this particular feature, or about some edge
> case that you've found that causes problems?
> 
 > This sounds to me like a misuse of sender to me. The sender is
> supposed to be a specific object that has sent the signal; a callable
> doesn't really meet that requirement. Internally, it's the id() of the
> python object that is used to key sender-based signals; I'm guessing
> in this case the sender should be the comment instance itself, not the
> callable that will produce the class that is used to produce comments.

It many cases we are free to use the result of a callable and a
callable interchangeably [x = y(); do(x) vs do(y())]. In these cases,
we may not, which is perfectly fine--as you say, there are Internal
and important reasons. I suppose a MoronException would be preferrable
to the ambiguous results I achieved (some were so subtle I didn't
realize until it was in production for a few days).

-Steve

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

Re: GSoC: Data importation class

[subs...@gmail.com]

Or let's circumvent the whole problem by stopping this garbage at the
gates!

On Mar 25, 11:34 pm, Richard Laager  wrote:
> This might be a bit off-topic for this thread, but legacy data is why I
> wish frameworks supported some concept of warnings in their validation
> code.
>
> Richard

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

Re: GSoC: Data importation class

[subs...@gmail.com]

> On 25/03/10 17:47, subs...@gmail.com wrote:
>
> >> The last bit sounds a bit nebulous. You could optimise it by not
> >> including any empty files, or be a bit more specific about what the
> >> empty files are meant to represent. :)
>
> > startapp, startproject, et al.
>
> I see where you're coming from here; in the final proposal, though,
> you'd want to follow Malcom's advice and have an actual use case for
> each file. I'd say you probably only want one, or even none - if your
> approach is so complicated that even simple use cases need lots of
> files, you're unlikely to get much traction.

The way I see it, you need  1) a stage directory with 2)
conversions.py for your conversion classes 3) legacy_models.py 4)
legacy_routers.py (potentially)

> South does have an answer to this - you create the columns as nullable,
> add in the data, and then alter them back to non-nullable. That's the
> only way a database is going to let you add a column; they need either a
> global default or NOT NULL (there are some cases you can do it, but
> they're really not appropriate for most people).
>
> In fact, I'd say this fits perfectly into the South model; one migration
> to make the two/three new tables, one that moves all the data around
> using the ORM (something Django developers know, and mostly love), and
> one to delete the old table. If you only use --auto then yes, it's only
> good at tracking small changes, but the rest of the power is right
> there, you just have to actually write code.

Sorry, I find this a bit awkward. I suspect if it was all as kosher as
you suggest, you'd be doing it yourself instead of pure scripting.
Moreover, it presumes a schema-similarity and cleanliness of data
which legacy data, by and large, can't be trusted with. This whole
approach is basically, accept the legacy schema as it is and work it
incrementally into a shape that looks like your modern schema.
Hopefully you arrive! I'm skeptical.

> Actually, most of my data import scripts are while loops over
> cursor.fetchall(), which just use the ORM to put in new data. With
> MultiDB, I probably won't even need the cursor part, I can just loop
> over the legacy model and insert into the new one.

Well, exactly. That's how all of these types of scripts work. I
suppose after I did this 3 times I found the whole business a bit
repetitious, not to mention what I ended up with was a 500 line series
of loops, probably split into multiple files so I could run them
independently. And, at the end of the day, 100% trash code. What I
hope for was a tool that helped me logically partition this work, and
free me to marshall it with minimum hassle, so that I could run and re-
run it until, at the end of the day, it came out cleanly.

> While it might be nice to make this more generic, each of those while
> loops has slightly different bodies - correcting coordinates here,
> fixing postcodes there - and the generic bits only take up one or two
> lines each time.

Sure, a datetime formatter is potentially as little as 3 or 4 lines,
but re-usable across dozens of fields, to say nothing of re-usability
between conversion projects.

> I'd really like to see a more compact or succinct way of doing this, but
> I'm dubious as to how flexible it would be. I'm more than happy to be
> proven wrong, however.

class Conversion():
date_added = legacy_date_added(format=funky_datetime_formatter)

> I read your initial proposal here as "code things in a sensible way",
> not "actively monitor performance and correct on the fly". Using
> pagination and making sure there's no memory leaks in the code's loops
> is a great idea, attempting to self-optimise at runtime probably isn't.

Yeah, I don't know where this active monitor stuff came up. But yeah,
pagination among others. There are other ideas, such as tying in
contenttypes and allowing users to see just how their legacy data
converted--immensely helpful in detecting problems.

I would love to see a "perfectionists with deadlines" approach catch
on in this area. I hearing from potential clients how much other
companies quote them for data conversion. Its always something like
$100/hr @ 20 hours. I'm glad when I can offer the same service at 4
hours. That on top of all the other borderline magic of Django.

-Steve

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

Re: GSoC: Data importation class

[subs...@gmail.com]

> > Adding system administration functionality to Django, which is what this
> > monitoring is, feels like the wrong approach.

I see here you probably meant its appropriate elsewhere but not in
django. Gotcha. Thought I'd try anyhow.

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

Re: GSoC: Data importation class

[subs...@gmail.com]

On Mar 25, 12:34 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> Hi,
>
> I see a few problems here. The gist of what follows is that it seems a
> bit abstract and as one tries to nail down the specifics it either
> devolves to a more-or-less already solved problem that doesn't require
> Django core changes, or a problem that is so unconstrained as to not be
> solvable by a framework (requiring, instead the full power of Python,
> which is already in the developer's hands).

In situations where inspectdb doesn't work, I've found its much less
work to get data into a shape where it _will_ work, rather than
resorting to scripting the entirety.

> On Thu, 2010-03-25 at 09:07 -0700, subs...@gmail.com wrote:
> > mix). With talk of model-level validation, the first approach is
> > becoming increasingly invalid,
>
> That's not a correct statement, since Django models can often be used to
> proscribe conditions on new data that is created via the web app, yet
> those conditions might not be required for the universal set of data
> that already exists. For example, webapp-generated data might always
> require a particular field, such as the creating user, to be filled in,
> whilst machine-generated data would not require that. Don't equate
> validation conditions at the model level with constraints on the data at
> the storage level.

I'm hard pressed to imagine a situation where I want validation to
only apply to incoming data. Out of laziness I might choose not to
apply some conditions to existing data as I did to a form, knowing
that the next time the user touches the record the validation will
kick in. This whole point seems to rest on a 'might' which I can't
recall ever encountering. Regardless, I tend to regard legacy data
with the same caution as I treat incoming user data, but it is
currently worlds more difficult to do the former compared to the
latter.

> The last bit sounds a bit nebulous. You could optimise it by not
> including any empty files, or be a bit more specific about what the
> empty files are meant to represent. :)

startapp, startproject, et al.

> It seems that you are talking about the cases where, by default, a
> different schema is required. The first approach is to make the models
> match the existing schema, on the grounds that the existing schema is a
> reasonable representation of the data. In the case where that isn't
> true, a migration is required, but the possibilities for such migrations
> are endless unless the original data can already be put into natural
> Django models. If inspectdb can already be run on the existing data, why
> not use that as the starting point and then the dev can use something
> like South to migrate to their schema of choice? It seems that we
> already have all the tools in that case.

South has a target use case of relatively simple changes to schema,
and assisting teams maintain synchronicity. However, it isn't long
before you're really pushing the limits of South. Take for example one
legacy model which needs to be split into two or three current models:
South has no answer for this as you may only use defaults for creation
of fields (in this case, foreign keys, or potentially OneToOnes, and
then what? What if my defaults are based on other values in that
record? Already, I'm on my own). By and large, South is an immaculate
tool for tracking changes during development.

> If inspectdb cannot generate a useful schema that can be modelled by
> Django, the user is going to have write a generic Python script in any
> case and the possibilities there are boundless and best left to the best
> tool available for the job at hand: Python itself.

In theory, yes. But in practice, I've found the shortest way around
the mountain is to get it into "SQL-enough" format manually. As for
Python, sure, but the more you write this monolithic script the more
you realize you're conducting a lot of repetitive work, the mechanics
of which are generally re-usable but an implementation which is
completely nuanced to your current task. If data importation is
something you do a lot, you've probably got a file somewhere holding
piecemeal bits that are hopefully vaguely useful to the next project,
all the while not being able to fight off the feeling that this
general task mirrors a lot of what goes on in forms with
clean_somefield() and clean().

> Adding system administration functionality to Django, which is what this
> monitoring is, feels like the wrong approach. It's not intended to
> replace everything else in your computing life. What is appropriate load
> usage for one case will be highly inappropriate elsewhere. How will you
> detect what you are labelling as "thrashing"?

I'm puzzled by this conclusion. The 'system administration
functionality' isn't in any way different to what you'd find in a

GSoC: Data importation class

[subs...@gmail.com]

If we could visualize the entirety of data within django-projects, we
would probably see that this 'data economy' is growing exponentially
year-over-year. However, I know of no guided way to actually get this
data into a project that's been converted to Django. There are two
methods I generally hear about when asking people how to move between
schemas: purely SQL solutions and one-shot scripted solutions (or a
mix). With talk of model-level validation, the first approach is
becoming increasingly invalid, but I wonder if we could include some
batteries for the second approach?

My proposal is a new django class which provides a mapping for how
this data should move from its legacy schema to a django project. I've
got a sort of proof-of-concept already working but it lacks the polish
of a refined community contribution. Moreover, with multi-database
support coming, I see this concept getting a shot in the arm,
especially in cases where the legacy db is a currently supported one.

I imagine the usage going something like:

1) User creates django project

2) User runs a 'startconversion' app which creates a stage folder for
holding an inspectdb of the legacy data, a default router for the
legacy data, and some other empty files.

3) User defines the classes which defines the map between the legacy
and new schema, and defines clean functions according to their needs,
'foreignkeys' to other conversion classes, etc.

4) User runs a command at the top branch of their schema (some distant
relation) and the command inspects these classes and runs them from
the ground up. As it does this measures are taken (such as use of
pagination) to avoid server CPU/memory thrashing, as well as model-
level measures such as OneToOne's being respect, etc.

-Steve

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

Potential bugs / need for extra documentation in 'Customizing the comments framework'

[subs...@gmail.com]

I got myself into a situation with a project and some comments models.
Perhaps with some discussion we can uncover genuine code-bugs, but my
knowledge about this is limited and so I'm just calling for a
documentation update. A major reason I'm asking for some notice of
these things to appear somewhere is that all of the below seems to
work perfectly fine in the dev server. On deployment, its a confusing
catastrophy that, at best, gives you a vague ImproperlyConfigured?
("The COMMENTS_APP setting refers to a non-existing package."), which
is of course no help at all.

Three things:

1) Its not obvious to me why, but importing a custom comment model as
'Comment' seems, somehow, to get back upstream to
django.contrib.comments and wreck things. If this is due to the nature
of that particular frameworks' immaculate ability to be extensive and
provide conveniences all around, so be it. I'd just like a notice next
time before I attempt to save code by doing Comment =
comments.get_model() and expect everything to be honkey dorey.

2) A custom comments app should not also be called 'comments'.
Probably a very obvious one but the problems it creates are
inconsistent between dev and live and not obvious.

3) Models hoping to foreignkey to whatever comments model the app
provides should not be passed the callable comments.get_model(). I
realize passing callables into a ForeignKey probably seems strange in
and of itself, however, once again it creates inconsistent problems
between dev and live which never connect back to the FK in any obvious
way.

4) Probably a dupe of above, but passing the callable into a signal as
sender also fails, and your signal is never respected.

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

Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

[subs...@gmail.com]

I guess at some point its just feature-clut. Its a use case we _could_
encompass, but would you really even find yourself using it?

I don't see the technical difference here--pre-syncdb, you either have
to 'wade' to the database or you have to 'wade' to this item in
settings.py. Its not as though you really need to create the same site
again and again. And if you do, there's fixtures.

-S

On Mar 14, 10:47 am, aditya  wrote:
> Fair enough. As Gabriel pointed out earlier, I didn't realize that I
> could change those values by adding django.contrib.sites to my
> INSTALLED_APPS. That's why I said there was no straightforward way of
> configuring those values.
>
> I wish Django had some sort of 'sample proposals' on their site. You
> say "provide a solution...which, preferably, leverages
> existing and proven features of Django" but to be honest I thought my
> solution did that already – it added nothing more than a try
> statement. How would I have made it any simpler than that?
>
> In any case, thanks for the response.
>
> On Mar 14, 6:27 am, James Bennett  wrote:
>
> > On Fri, Mar 12, 2010 at 4:39 PM, aditya  wrote:
> > > The trouble is, there is no straightforward way to configure the name
> > > and domain of a site.
>
> > Sure there is: create a Site object, or edit an existing one, setting
> > the values you want on it.
>
> > > Currently, Django uses "example.com" for both the domain and the
> > > name.  The only way to change that is to wade into the actual
> > > database.
>
> > You say this as if it's something obviously evil and horrible and
> > terrible, but provide no explanation of *why* it's bad. You then
> > propose solving this problem by adding two new settings to Django
> > which will be used only when syncdb installs the sites app and then
> > never referenced ever again.
>
> > If you want this proposal to be taken seriously, you'll need to:
>
> > 1. Explain why you think it's such a bad thing for a framework which
> > offers easy ways to interact with your database to... ask you to
> > interact with your database.
>
> > 2. If it turns out there's a real problem, provide a solution which
> > doesn't involve one-time settings and which, preferably, leverages
> > existing and proven features of Django rather than trying to add new
> > ones just for this case.
>
> > Admittedly these will be rather high hurdles, since I don't honestly
> > see what the problem is here; yes, you'll end up editing the default
> > Site object, but there are things which need a Site object to exist as
> > soon as contrib.sites is installed, and so we just default to the
> > safest possible thing: the example domain name reserved for this sort
> > of use by RFC2606.
>
> > --
> > "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-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Adding takes_context argument to filters

[subs...@gmail.com]

Hello there,

I'm interested in allowing a particular filter I have to check the
context. Trolling for reasons for and against, and if it makes no
difference I'll file a ticket and provide some patches.

Its useful for me in cases where the thing I am processing has already
been processed before. Take for example a wikification filter, which
converts the string "[[some name]]" into "some name".

{{ comments.comment | mark_safe | markdown | wikification }}

I don't want to hit the database twice in situations where
wikification has already called upon a particular model instance, so
as I'm processing comments its nice to build a dictionary in the
context as a cache. However, since tags and not filters are privvy to
the context, currently, I'm stuck with throwing out all these neat
filters, and wrapping their functionality in a tag.

The culrpit class is FilterExpression.resolve(). If I read it right,
its already manipulating the context anyway so there's no additional
load to pass it optionally to the filter function, if it asks.

-Steve

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

Re: Potential bug in select_related() as of Beta

[subs...@gmail.com]

Sorry to be pushy, but I would like to bump this or find the next tree
to bark up.

-S

On Feb 17, 9:42 pm, "subs...@gmail.com" <subs...@gmail.com> wrote:
> bmodels.Contact.objects.select_related('IR_contact','consumer_contact','pro­gram','consumer').filter(consumer__file=file).order_by('-
> date')
>
> Yeah, I figured as much.
>
> -S
>
> On Feb 17, 4:34 pm, Jeremy Dunck <jdu...@gmail.com> wrote:
>
>
>
> > Erm, and the queryset creation.
>
> > Also, people are en route to PyCon, so responses may be a bit slow.
>
> > On Wed, Feb 17, 2010 at 3:30 PM, subs...@gmail.com <subs...@gmail.com> 
> > wrote:
> > >http://dpaste.com/160722/
>
> > > class Contact(models.Model):
> > >    program = models.ForeignKey('agency.Program')
> > >    consumer =
> > > models.ForeignKey('consumer.Consumer',null=True,blank=True)
> > >    date = models.DateField('Contact Date')
> > >    notes = models.TextField()
> > >    date_added = models.DateTimeField(editable=False)
> > >    method =
> > > models.CharField(max_length=10,choices=choices.CONTACT_METHOD,\
> > >            null=True,blank=True)
>
> > > # consumer_contact
> > > class Contact(basemodels.Contact):
> > >    base = models.OneToOneField(basemodels.Contact,
> > > parent_link=True,related_name="consumer_contact")
> > >    service = models.ForeignKey(Service)
> > >    confidential = models.BooleanField(default=False,help_text='These
> > > notes will not be visible to general staff')
> > >    group = models.ForeignKey(Group,null=True,blank=True)
> > >    group_contact =
> > > models.ForeignKey('consumer.GroupContact',blank=True,null=True)
>
> > >    def save(self, *args, **kwargs):
> > >        super(Contact, self).save(*args,**kwargs)
>
> > >    class Meta:
> > >        permissions = (
> > >            ("allow_confidential", "Can make contacts confidential"),
> > >        )
>
> > > #ir_contact
> > > class Contact(basemodels.Contact):
>
> > > base=models.OneToOneField(BaseContact,parent_link=True,related_name='IR_con­tact')
> > >    IR=models.ForeignKey(IR,blank=True,null=True)
>
> > > referred_from=models.ForeignKey(ReferralSource,related_name='IR_referred_fr­om')
>
> > > referred_to=models.ManyToManyField(ReferralSource,related_name='IR_referred­_to')
>
> > > information=models.ManyToManyField(Information,verbose_name='Information
> > > Requested')
>
> > > On Feb 17, 4:15 pm, Jeremy Dunck <jdu...@gmail.com> wrote:
> > >> We'll need your model definitions in order to help much.
>
> > >> On Wed, Feb 17, 2010 at 2:54 PM, Steve <subs...@gmail.com> wrote:
> > >> > Hello all,
>
> > >> > I believeselect_relatedis creating some extraneous joins in situations
> > >> > where one is joining child models from a base model (model 
> > >> > inheritance).
>
> > >> > Take the following SQL generated (dpaste here, probably more readable
> > >> >http://dpaste.com/160677/)
>
> > >> > 
>
> > >> > SELECT (fields) FROM `base_contact`
>
> > >> > LEFT OUTER JOIN `consumer_consumer` ON (`base_contact`.`consumer_id` =
> > >> > `consumer_consumer`.`id`) # ok
>
> > >> > INNER JOIN `agency_program` ON (`base_contact`.`program_id` =
> > >> > `agency_program`.`id`) # ok
>
> > >> > LEFT OUTER JOIN `consumer_contact` ON (`base_contact`.`id` =
> > >> > `consumer_contact`.`base_id`) # ok
>
> > >> > INNER JOIN `base_contact` T5 ON (`consumer_contact`.`base_id` = 
> > >> > T5.`id`) #
> > >> > ?!?
>
> > >> > # These next two are questionable, since they are joined on a LEFT 
> > >> > OUTER (so
> > >> > they may potentially not be there)
>
> > >> > INNER JOIN `consumer_service` ON (`consumer_contact`.`service_id` =
> > >> > `consumer_service`.`id`)
>
> > >> > INNER JOIN `consumer_servicetype` ON (`consumer_service`.`type_id` =
> > >> > `consumer_servicetype`.`id`)
>
> > >> > LEFT OUTER JOIN `IR_contact` ON (`base_contact`.`id` =
> > >> > `IR_contact`.`base_id`)  # ok
>
> > >> > INNER JOIN `base_contact` T9 ON (`IR_contact`.`base_id` = T9.`id`) # 
> > >> > ?!?
>
> > >> > WHERE `consumer_consumer`.`file` = 06-1757 ORDER BY 

Re: Potential bug in select_related() as of Beta

[subs...@gmail.com]

bmodels.Contact.objects.select_related('IR_contact','consumer_contact','program','consumer').filter(consumer__file=file).order_by('-
date')

Yeah, I figured as much.

-S


On Feb 17, 4:34 pm, Jeremy Dunck <jdu...@gmail.com> wrote:
> Erm, and the queryset creation.
>
> Also, people are en route to PyCon, so responses may be a bit slow.
>
> On Wed, Feb 17, 2010 at 3:30 PM, subs...@gmail.com <subs...@gmail.com> wrote:
> >http://dpaste.com/160722/
>
> > class Contact(models.Model):
> >    program = models.ForeignKey('agency.Program')
> >    consumer =
> > models.ForeignKey('consumer.Consumer',null=True,blank=True)
> >    date = models.DateField('Contact Date')
> >    notes = models.TextField()
> >    date_added = models.DateTimeField(editable=False)
> >    method =
> > models.CharField(max_length=10,choices=choices.CONTACT_METHOD,\
> >            null=True,blank=True)
>
> > # consumer_contact
> > class Contact(basemodels.Contact):
> >    base = models.OneToOneField(basemodels.Contact,
> > parent_link=True,related_name="consumer_contact")
> >    service = models.ForeignKey(Service)
> >    confidential = models.BooleanField(default=False,help_text='These
> > notes will not be visible to general staff')
> >    group = models.ForeignKey(Group,null=True,blank=True)
> >    group_contact =
> > models.ForeignKey('consumer.GroupContact',blank=True,null=True)
>
> >    def save(self, *args, **kwargs):
> >        super(Contact, self).save(*args,**kwargs)
>
> >    class Meta:
> >        permissions = (
> >            ("allow_confidential", "Can make contacts confidential"),
> >        )
>
> > #ir_contact
> > class Contact(basemodels.Contact):
>
> > base=models.OneToOneField(BaseContact,parent_link=True,related_name='IR_contact')
> >    IR=models.ForeignKey(IR,blank=True,null=True)
>
> > referred_from=models.ForeignKey(ReferralSource,related_name='IR_referred_from')
>
> > referred_to=models.ManyToManyField(ReferralSource,related_name='IR_referred_to')
>
> > information=models.ManyToManyField(Information,verbose_name='Information
> > Requested')
>
> > On Feb 17, 4:15 pm, Jeremy Dunck <jdu...@gmail.com> wrote:
> >> We'll need your model definitions in order to help much.
>
> >> On Wed, Feb 17, 2010 at 2:54 PM, Steve <subs...@gmail.com> wrote:
> >> > Hello all,
>
> >> > I believe select_related is creating some extraneous joins in situations
> >> > where one is joining child models from a base model (model inheritance).
>
> >> > Take the following SQL generated (dpaste here, probably more readable
> >> >http://dpaste.com/160677/)
>
> >> > 
>
> >> > SELECT (fields) FROM `base_contact`
>
> >> > LEFT OUTER JOIN `consumer_consumer` ON (`base_contact`.`consumer_id` =
> >> > `consumer_consumer`.`id`) # ok
>
> >> > INNER JOIN `agency_program` ON (`base_contact`.`program_id` =
> >> > `agency_program`.`id`) # ok
>
> >> > LEFT OUTER JOIN `consumer_contact` ON (`base_contact`.`id` =
> >> > `consumer_contact`.`base_id`) # ok
>
> >> > INNER JOIN `base_contact` T5 ON (`consumer_contact`.`base_id` = T5.`id`) 
> >> > #
> >> > ?!?
>
> >> > # These next two are questionable, since they are joined on a LEFT OUTER 
> >> > (so
> >> > they may potentially not be there)
>
> >> > INNER JOIN `consumer_service` ON (`consumer_contact`.`service_id` =
> >> > `consumer_service`.`id`)
>
> >> > INNER JOIN `consumer_servicetype` ON (`consumer_service`.`type_id` =
> >> > `consumer_servicetype`.`id`)
>
> >> > LEFT OUTER JOIN `IR_contact` ON (`base_contact`.`id` =
> >> > `IR_contact`.`base_id`)  # ok
>
> >> > INNER JOIN `base_contact` T9 ON (`IR_contact`.`base_id` = T9.`id`) # ?!?
>
> >> > WHERE `consumer_consumer`.`file` = 06-1757 ORDER BY `base_contact`.`date`
> >> > DESC
>
> >> > 
>
> >> > There are two joins I simply can't explain (marked "?!?"). Removing them
> >> > gives me my expected results. select_related in on case seems to 
> >> > correctly
> >> > create a LEFT OUTER, but then follows up by creating an unwanted INNER.
>
> >> > Keep in mind I made a note about the 'questionable' join above, but even
> >> > removing that entirely creates the same problem.
>
> >> > I'll be glad to file a ticket, if the issue is something other t

Re: Potential bug in select_related() as of Beta

[subs...@gmail.com]

http://dpaste.com/160722/

class Contact(models.Model):
program = models.ForeignKey('agency.Program')
consumer =
models.ForeignKey('consumer.Consumer',null=True,blank=True)
date = models.DateField('Contact Date')
notes = models.TextField()
date_added = models.DateTimeField(editable=False)
method =
models.CharField(max_length=10,choices=choices.CONTACT_METHOD,\
null=True,blank=True)

# consumer_contact
class Contact(basemodels.Contact):
base = models.OneToOneField(basemodels.Contact,
parent_link=True,related_name="consumer_contact")
service = models.ForeignKey(Service)
confidential = models.BooleanField(default=False,help_text='These
notes will not be visible to general staff')
group = models.ForeignKey(Group,null=True,blank=True)
group_contact =
models.ForeignKey('consumer.GroupContact',blank=True,null=True)

def save(self, *args, **kwargs):
super(Contact, self).save(*args,**kwargs)

class Meta:
permissions = (
("allow_confidential", "Can make contacts confidential"),
)

#ir_contact
class Contact(basemodels.Contact):
 
base=models.OneToOneField(BaseContact,parent_link=True,related_name='IR_contact')
IR=models.ForeignKey(IR,blank=True,null=True)
 
referred_from=models.ForeignKey(ReferralSource,related_name='IR_referred_from')
 
referred_to=models.ManyToManyField(ReferralSource,related_name='IR_referred_to')
 
information=models.ManyToManyField(Information,verbose_name='Information
Requested')


On Feb 17, 4:15 pm, Jeremy Dunck <jdu...@gmail.com> wrote:
> We'll need your model definitions in order to help much.
>
> On Wed, Feb 17, 2010 at 2:54 PM, Steve <subs...@gmail.com> wrote:
> > Hello all,
>
> > I believe select_related is creating some extraneous joins in situations
> > where one is joining child models from a base model (model inheritance).
>
> > Take the following SQL generated (dpaste here, probably more readable
> >http://dpaste.com/160677/)
>
> > 
>
> > SELECT (fields) FROM `base_contact`
>
> > LEFT OUTER JOIN `consumer_consumer` ON (`base_contact`.`consumer_id` =
> > `consumer_consumer`.`id`) # ok
>
> > INNER JOIN `agency_program` ON (`base_contact`.`program_id` =
> > `agency_program`.`id`) # ok
>
> > LEFT OUTER JOIN `consumer_contact` ON (`base_contact`.`id` =
> > `consumer_contact`.`base_id`) # ok
>
> > INNER JOIN `base_contact` T5 ON (`consumer_contact`.`base_id` = T5.`id`) #
> > ?!?
>
> > # These next two are questionable, since they are joined on a LEFT OUTER (so
> > they may potentially not be there)
>
> > INNER JOIN `consumer_service` ON (`consumer_contact`.`service_id` =
> > `consumer_service`.`id`)
>
> > INNER JOIN `consumer_servicetype` ON (`consumer_service`.`type_id` =
> > `consumer_servicetype`.`id`)
>
> > LEFT OUTER JOIN `IR_contact` ON (`base_contact`.`id` =
> > `IR_contact`.`base_id`)  # ok
>
> > INNER JOIN `base_contact` T9 ON (`IR_contact`.`base_id` = T9.`id`) # ?!?
>
> > WHERE `consumer_consumer`.`file` = 06-1757 ORDER BY `base_contact`.`date`
> > DESC
>
> > 
>
> > There are two joins I simply can't explain (marked "?!?"). Removing them
> > gives me my expected results. select_related in on case seems to correctly
> > create a LEFT OUTER, but then follows up by creating an unwanted INNER.
>
> > Keep in mind I made a note about the 'questionable' join above, but even
> > removing that entirely creates the same problem.
>
> > I'll be glad to file a ticket, if the issue is something other than my
> > ignorance.
>
> > -Steve
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.

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

Re: Multiple database support: Request for feedback and testing

[subs...@gmail.com]

Oh, I see from a later message by Alex that Meta.using was removed.

-1!

-S

On Dec 5, 3:12 pm, "subs...@gmail.com" <subs...@gmail.com> wrote:
> Isn't 'database' going to be an option in a model's Meta? In this
> situation, is admin going to attempt to do something different?
>
> -S
>
> On Dec 4, 9:18 am, Nan <ringe...@gmail.com> wrote:
>
> > > 1) Ignore the problem. Admin works on the default database, but
> > > nowhere else. This is certainly less than ideal, but it would be
> > > sufficient for master/slave setups.
>
> > > 2) Use a separate admin deployment for each database. We add a 'using'
> > > argument to admin.Site(), and append .using() the queries that the
> > > admin site issues.
>
> > > 3) Modify the admin list views so that they take a ?using=db GET
> > > argument; also add a pulldown to make it easy to switch to a different
> > > database.
>
> > > (2) should be a fairly minor change; (3) would be a little more
> > > effort, but shouldn't be impossible. There is also the need for some
> > > mechanics to check whether a table is actually present on a database -
> > > just because auth is in INSTALLED_APPS doesn't mean it's been
> > > synchronized to a particular database.
>
> > > I'm open to any other suggestions - and for any offers to help out :-)
>
> > Just thinking of one more option for this -- what about specifying the
> > DB on the ModelAdmin level rather than the admin.Site level?

--

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

Re: Multiple database support: Request for feedback and testing

[subs...@gmail.com]

Isn't 'database' going to be an option in a model's Meta? In this
situation, is admin going to attempt to do something different?

-S

On Dec 4, 9:18 am, Nan  wrote:
> > 1) Ignore the problem. Admin works on the default database, but
> > nowhere else. This is certainly less than ideal, but it would be
> > sufficient for master/slave setups.
>
> > 2) Use a separate admin deployment for each database. We add a 'using'
> > argument to admin.Site(), and append .using() the queries that the
> > admin site issues.
>
> > 3) Modify the admin list views so that they take a ?using=db GET
> > argument; also add a pulldown to make it easy to switch to a different
> > database.
>
> > (2) should be a fairly minor change; (3) would be a little more
> > effort, but shouldn't be impossible. There is also the need for some
> > mechanics to check whether a table is actually present on a database -
> > just because auth is in INSTALLED_APPS doesn't mean it's been
> > synchronized to a particular database.
>
> > I'm open to any other suggestions - and for any offers to help out :-)
>
> Just thinking of one more option for this -- what about specifying the
> DB on the ModelAdmin level rather than the admin.Site level?

--

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

Re: App Engine port

[subs...@gmail.com]

Basic demand side problem. When an app stands up and solves the real
issues (which, as the DjangoCon presentation proved, there were many)
involving App Engine and Django, then I (and the demographic of
developers I statistically represent) will become excited.

-S

On Feb 6, 9:51 am, David Stenglein  wrote:

> If so, why the seeming lack of excitement around App Engine? Are
> google engineers not involved in the community?
>
> -Dave
>
> On Fri, Feb 6, 2009 at 7:10 AM, Russell Keith-Magee
>
>  wrote:
>
> > On Fri, Feb 6, 2009 at 8:32 PM, Waldemar Kornewald  
> > wrote:
>
> >> Hi Russell,
>
> >> On 6 Feb., 11:34, Russell Keith-Magee  wrote:
> >>> I would suggest to you that the broader project of "modifying the
> >>> django.db.models interface to be fully independent of SQL" is much
> >>> more likely to get core developer support. We (the Django core) will
> >>> be very receptive to any suggestions on how django.db.models needs to
> >>> be modified in order to support non-SQL backends -- especially if you
> >>> can demonstrate that your suggestions aren't just theoretical, but are
> >>> clearly required by an actual backend implementation.
>
> >> Agreed, making models SQL-independent is the most important (and most
> >> complicated) part. Do the people secretly working on App Engine
> >> integration try to implement that part?
>
> > I haven't seen their code, so I can't say for certain, but I imagine
> > that they have a small collection of patches for the main Django tree
> > that enables their backend to be independent of SQL.
>
> >>> If you are maintaining an external project handling AppEngine support
> >>> for Django, then that project's wiki is the right place for
> >>> documentation about AppEngine support within Django. While AppEngine
> >>> support isn't part of Django's core, Django's wiki isn't the right
> >>> place to be providing AppEngine specific instructions - especially if
> >>> the first instruction is "install this third party project that isn't
> >>> formally affiliated with the Django project at this time".
>
> >> I can't find anything like that in my wiki page. It describes what is
> >> necessary for a completely new port that has practically nothing to do
> >> with app-engine-patch apart from being able to reuse some of the
> >> existing code. It could be useful for any porting effort. If I keep it
> >> in my wiki nobody else can work on that page. It's almost useless that
> >> way.
>
> > Ok - sounds like they could be some good contributions. I just wanted
> > to make sure you were not planning on making the Django wiki the home
> > of the "how to use app-engine-patch" documentation.
>
> > Yours,
> > Russ Magee %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---