Re: Ticket #5373

[Lachlan Musicman]

On Fri, Jul 9, 2010 at 00:00, Russell Keith-Magee
 wrote:
> On Thu, Jul 8, 2010 at 3:55 PM, Lachlan Musicman  wrote:
>> Hola,
>>
>> I'm new to this dev thing, but I've done some work on ticket #5373
>
> Thanks for pitching in! Hopefully I'll be able to give you enough
> feedback to progress this issue without scaring you off :-)

That would be great, cheers

> I agree that the first patch (.2.patch) isn't the right approach --
> isinstance checks are generally an indication that you're doing
> something wrong (or at least that you could be doing it better).

Yeah, I knew that, just didn't have the eloquence

> However, I'm also concerned about unexpected consequences for the
> second patch. The obvious use case that you're breaking is if your
> ForeignKey manually defines a verbose_name.

I'm not quite sure I understand. Does that mean we can have
conflicting verbose_names? My mental unrolling of your advice brings
me to:

eg 1:
class Book(models.Model):
name = models.CharField(max_length=50)

class Meta:
verbose_name = _(u'Novel')
verbose_name_plural = _(u'Novels')

class Author(models.Model):
name = models.CharField(max_length=50)
books = models.ManyToManyField(Book, verbose_name=_(u'Paperback'))

In this (ugly, but possible?) case, we have conflicting verbose names.
Which should take precedence? Your note would indicate that Paperback
should?


> So - the next step is to make the tests more robust; you'll either
> prove that this isn't a problem, or you'll find the edge case that
> needs to be fixed.

It's definitely a problem - I've started this because it's one I experience :)

> would be at a lower level -- in this case, testing that foreign key
> fields return an appropriate verbose_name, and/or that ModelForms pick
> up a translated verbose name.

Got it - am working on it now.

cheers
L.

-- 
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: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

[Alex Gaynor]

On Sat, Jul 10, 2010 at 7:24 AM, Russell Keith-Magee
 wrote:
> On Sat, Jul 10, 2010 at 12:49 AM, Carl Meyer  wrote:
>> On Jul 7, 7:11 pm, Graham Dumpleton 
>> wrote:
>> [snip]
>>> web application, to be a well behaved WSGI citizen, should honour
>>> SCRIPT_NAME setting as supplied by the server, and ensure that ways
>>> are provided such that everything in the users code, including
>>> configuration, urls or settings files, can be expressed relative to
>>> the URL that the application is mounted at, thereby avoiding as much
>>> as possible any need for a user to modify their code base when
>>> deploying to a new environment at a different location in URL
>>> namespace.
>>
>> IMO one root problem here (which has been discussed before) is that
>> settings.py conflates "deployment config" with "application config"
>> and thus tends to lead to fuzzy thinking about which is which (which
>> causes problems especially for larger organizations with separate
>> teams for development and ops). Application config should not have to
>> change between different deployments of the same codebase; deployment
>> config almost certainly will.
>>
>> The status quo makes LOGIN_URL (and friends) themselves a mishmash of
>> deployment config and application config; i.e. the initial
>> "application mount point" portion is deployment config, and the rest
>> is clearly application config (it would only change if the URLconf
>> changes). This seems like a bad thing to me: the ops team shouldn't
>> have to understand the internal layout of the application's urls in
>> order to deploy it correctly.
>
> This is a certainly a criticism I would agree with. An improved app
> config/deployment config distinction is a broad goal that is worth
> striving for.
>
>> Wouldn't it be most sensible to treat the URL mount point similarly to
>> hostname, since they are really just two pieces of the same data: the
>> deployed root URL of the application? (Practically speaking, this
>> could mean a new field in contrib.sites.Site, or allowing/condoning
>> "example.com/something" as a value for the domain field, and extending
>> RequestSite to do the same by checking SCRIPT_NAME).
>
> I'm not sure I understand exactly what you're describing here. Lets
> say we modify Site, and I have the mount point data described in my
> Site.objects.get_current() instance; are you proposing that anywhere
> that you use LOGIN_URL, we should be prepending site.mount_point (or
> whatever the bikeshed looks like)?
>
> If so, how do we get from here to there? For better or worse, if
> you're deploying a Django site at a non-root SCRIPT_NAME, you will
> have a LOGIN_URL that includes that SCRIPT_NAME; how do you propose
> that we transition to a mount-point based interpretation?
>
> 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 at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

It seems to me the easy answer is to always pass it through
"redirect", which will do the right thing on an absolute URL, but also
handle reverse.

Alex

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

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

Re: natural keys and dumpdata

[Simon Meers]

> I'll put it on my todo list; if anyone else wants to give it a sanity
> check, I'd appreciate the extra eyeballs.

Looks pretty sane to me, though I wonder if the deserialisation should
raise an exception if the pk is missing and an incomplete set of
natural key fields is provided? Nice work, thanks Chris.

-- 
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: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

[Russell Keith-Magee]

On Sat, Jul 10, 2010 at 12:49 AM, Carl Meyer  wrote:
> On Jul 7, 7:11 pm, Graham Dumpleton 
> wrote:
> [snip]
>> web application, to be a well behaved WSGI citizen, should honour
>> SCRIPT_NAME setting as supplied by the server, and ensure that ways
>> are provided such that everything in the users code, including
>> configuration, urls or settings files, can be expressed relative to
>> the URL that the application is mounted at, thereby avoiding as much
>> as possible any need for a user to modify their code base when
>> deploying to a new environment at a different location in URL
>> namespace.
>
> IMO one root problem here (which has been discussed before) is that
> settings.py conflates "deployment config" with "application config"
> and thus tends to lead to fuzzy thinking about which is which (which
> causes problems especially for larger organizations with separate
> teams for development and ops). Application config should not have to
> change between different deployments of the same codebase; deployment
> config almost certainly will.
>
> The status quo makes LOGIN_URL (and friends) themselves a mishmash of
> deployment config and application config; i.e. the initial
> "application mount point" portion is deployment config, and the rest
> is clearly application config (it would only change if the URLconf
> changes). This seems like a bad thing to me: the ops team shouldn't
> have to understand the internal layout of the application's urls in
> order to deploy it correctly.

This is a certainly a criticism I would agree with. An improved app
config/deployment config distinction is a broad goal that is worth
striving for.

> Wouldn't it be most sensible to treat the URL mount point similarly to
> hostname, since they are really just two pieces of the same data: the
> deployed root URL of the application? (Practically speaking, this
> could mean a new field in contrib.sites.Site, or allowing/condoning
> "example.com/something" as a value for the domain field, and extending
> RequestSite to do the same by checking SCRIPT_NAME).

I'm not sure I understand exactly what you're describing here. Lets
say we modify Site, and I have the mount point data described in my
Site.objects.get_current() instance; are you proposing that anywhere
that you use LOGIN_URL, we should be prepending site.mount_point (or
whatever the bikeshed looks like)?

If so, how do we get from here to there? For better or worse, if
you're deploying a Django site at a non-root SCRIPT_NAME, you will
have a LOGIN_URL that includes that SCRIPT_NAME; how do you propose
that we transition to a mount-point based interpretation?

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 at 
http://groups.google.com/group/django-developers?hl=en.

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

[Russell Keith-Magee]

On Sat, Jul 10, 2010 at 12:19 AM, burc...@gmail.com  wrote:
> Tom,
>
> HTTP_HOST and other don't solve the multiple-host deployment, and it
> is a solution you can do by yourself if you need.
>
> I'd like to see better solution: ability to make reverse work for such URLs.
> I think, currently the problem is in the binding time:
>
> The load order is typically the following:
> settings.py
> */urls.py
> */models.py
> */admin.py
> */views.py
>
> This is not mentioned anywhere (or is it?), but if this order is
> broken, "cycle in imports" errors will probably occur.

This order isn't enforced at all. settings.py shouldn't be importing
anything -- it should just be simple settings, and maybe some light
logic to accommodate complex configurations. Other than that, you just
need to avoid circular imports -- but that's not a Django specific
issue. Circular imports are an issue in almost every language I can
think of.

> So you can't put reverse now in settings.py unless there is some
> late-binding construct, like
>
> LOGIN_URL = RevLink('accounts:login', account_type='user')

You shouldn't have to put reverse() calls into settings.py -- you
should only have to provide the name. That's the point of having named
URLs. Resolution should be happing at runtime, not at time of
definition.

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 at 
http://groups.google.com/group/django-developers?hl=en.

Re: natural keys and dumpdata

[Stijn Hoop]

Hello,

On Jul 9, 9:13 pm, SmileyChris  wrote:
> It seems that my ticket in http://code.djangoproject.com/ticket/13252
> covers this. It's ready for review if anyone wants to give it a
> spin...

That patch indeed matches mine, but yours is of course much further
along.

Javier Guerra Giraldez wrote:
> the best solution isn't natural keys (which are so very seldom a good
> idea); what you need is UUIDs.

Until the patch above is included I will check out using a primary key
UUID field, that should certainly do the trick as well.

Thanks for the suggestions all!

--Stijn

-- 
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: Regression problem on admin date format

[Antoni Aloy]

2010/7/10 Russell Keith-Magee :
> On Sat, Jul 10, 2010 at 1:15 AM, Antoni Aloy  wrote:

> Are you sure that this is a regression, rather than a bugfix with
> unfortunate side effects? In particular, I draw your attention to the
> second note under:
>
> http://docs.djangoproject.com/en/1.2/topics/i18n/localization/#id3
>

Well I don't know how to call it, but I just see the effects. I'm not
talking about a custom form, it's about the admin form, and I'm just
using USE_L18N=True, so I understand that admin should work  in the
same way 1.2 was.

Actually you have the right display format when intering a date with
the calendar or the "today" link, but the wrong (default one) the
first time the date is displayed.

And if you modify a non date field the form will complain about the
wrong date format.

Best regards,

-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

-- 
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: Enhanced URL Resolver Match

[Russell Keith-Magee]

On Fri, Jul 9, 2010 at 1:50 PM, Nowell Strite  wrote:
> When Django 1.1 was released URLs gained the ability to be nested with
> namespaces by adding "app_name" and "namespace" attributes to the
> include(...) functions within urls.py. The reverse(...) function was
> updated to allow you to specify namespace and current_app when
> resolving URLs, however, we never brought the resolve(...) function up
> to speed to include the relevant namespace and app_name data of the
> resolved URL. I have taken an initial stab with code and tests (minus
> documentation, until this feature is completed and agreed upon by the
> community).
>
> In order to achieve this I have graduated the result of the
> resolve(...) method to be a ResolverMatch class as opposed to the old
> tuple(func, args, kwargs). I have also implemented this feature to
> provides backwards compatibility for the old "func, args, kwargs =
> resolve(...)" so this feature should hopefully be completely backwards
> compatible. The new ResolverMatch class provides access to all
> attributes of the resolved URL match such as (url_name, app_name,
> namespace, func, args, kwargs).
>
> Please take a look and let me know what you think of the direction and
> implementation:
>
> http://github.com/nowells/django/compare/master...resolver-match

I'll need to do a detailed teardown before I commit, but on a first
inspection, this looks pretty good to me.

If there isn't a ticket for this already, could you please open one
and include a reference to your github branch (and/or upload the
patch). Once there are some docs, I'm happy for this to be RFC for
1.3.

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 at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django Model Related Manager Enhancements

[Russell Keith-Magee]

On Thu, Jul 8, 2010 at 10:45 PM, Nowell Strite  wrote:
> Recently I started working on a project (django-versions) to enable
> versioning of model data with Mercurial. In doing so, I came across
> the need to have access to more data about the relationships that
> Django Related Manager's create. For example, I wanted to be able to
> access the instance of the model that a related manager was called
> from, as well as the field names for the forward and reverse
> relationship.

You won't get any argument from me that this sort of metadata should
be available; however, I'm fairly certain it already is:

artist1.songs.model_attname
==> Artist.songs.field.rel.related_name

artist1.songs.related_model_instance
===> artist1 (not sure why this one is required)

artist1.songs.related_model_attname
==> Artist.songs.field.name

Have I missed something?

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 at 
http://groups.google.com/group/django-developers?hl=en.

Re: Regression problem on admin date format

[Russell Keith-Magee]

On Sat, Jul 10, 2010 at 1:15 AM, Antoni Aloy  wrote:
> Hello,
>
> Have anybody (Marc Garcia ?) check
> http://code.djangoproject.com/ticket/13621 ticket. It explains a bug
> concerning date and time formats. The admin does not conform the i18n
> locale settings on displaying time and date formats and reverts to the
> default format.
>
> It seems a true regression test as
> http://djangoadvent.com/1.2/i18n-l10n-improvements/ explains the right
> display. I have reverted to Django 1.2.0 and the display works
> perfectly.
>
> As you can imagine is a quite annoying bug for non-english date format
> users, perhaps enough to make a 1.2.2 release.

Are you sure that this is a regression, rather than a bugfix with
unfortunate side effects? In particular, I draw your attention to the
second note under:

http://docs.djangoproject.com/en/1.2/topics/i18n/localization/#id3

The reason for this change is that Python's date parsing libraries
aren't thread safe, so parsing internationalized date/time components
like AM/PM are problematic.

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 at 
http://groups.google.com/group/django-developers?hl=en.

Re: natural keys and dumpdata

[Russell Keith-Magee]

On Sat, Jul 10, 2010 at 3:13 AM, SmileyChris  wrote:
> On Jul 10, 1:47 am, Stijn Hoop  wrote:
>> Hi,
>>
>> I am trying to use the 'natural keys' feature of django to make a sort
>> of "future proof" fixture loading possible.
>> [...]
>> With the patch linked below[1] I have successfully used dumpdata and
>> loaddata for a .json export of my tables. Of course I would like to
>> see something like this accepted, but this is of course a sort of
>> "feature request".
>
> It seems that my ticket in http://code.djangoproject.com/ticket/13252
> covers this. It's ready for review if anyone wants to give it a
> spin...

I'll put it on my todo list; if anyone else wants to give it a sanity
check, I'd appreciate the extra eyeballs.

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 at 
http://groups.google.com/group/django-developers?hl=en.

Re: New admin feature: Delete and replace with existing object

[Russell Keith-Magee]

On Fri, Jul 9, 2010 at 10:37 PM, Ric  wrote:
> i'll reply one by one
>
>  * What if you have multiple models referring to Author? Do you
> assume
> that every related model will be updated the same way?
>
>  * What if you have multiple foreign keys from Blog to Author? Do you
> assume that every foreign key on a single model will be updated in
> the
> same way?
>
> i dont' think this is an issue, we do not need to reinvent the wheel.
> django uses get_deleted_objects to retrieve all related objects
>
> (deleted_objects, perms_needed) = get_deleted_objects((obj,), opts,
> request.user, self.admin_site)
>
> we can use this feature, and then do a function that cycle and update,
> or for a more efficient alghoritm we can use a queryset update.
>
> but maybe it's better to call method save on every single object
> beacause the save method could be customized.
>
>  * What if you use admin actions to delete N authors? Do we assume
> that every one of the authors will be replaced with the same single
> substitute?
>
> I think yes, beacuse as you said before, a mutiple user choose would
> be not so user friendly.
>
> but we can define an attr, something like
> admin.ModelAdmin.replace_multiple_objects = True
> if True, for every object will be created a replacer field... but i
> think this is difficult to archive, and not so smart...
>
>
> I think that this behaviour is indipendent from the model. and i don't
> think there are different interpretations of this feature.
>
> let me explain:
> you are going to delete an object.
> django is saying to you: "in order to preserve database integrity, i
> have to delete all this object."
>
> do you want to delete them or you want to substitute with another one?

I understand this. What you seem to be missing is that in the general
case, there isn't a single, canonical answer that will *always* be
correct.

If you are deleting 1 object, there are O(N*M) objects that need to be
updated, where N is the number of models X that have a relation to the
object being deleted, and M is the number of instances of X that have
a relation to the object being deleted.

As an example: I have an Author, Article and Address record. Article
and Address both have a FK on Author. If I delete Author "John", I
need to do something to any Article and Address record that points at
John. In my business logic, I want to update all Articles to point at
a dummy author, but I want to cascade delete all the Address records.

To complicate issues some more - lets say I want some Article records
to point at a dummy author, and some to point at a new author that is
going to take responsibility. I need to be able to select which
authors will be applied to which articles. There might even be a
programatic scheme that I can use to semi-automate this reassignment
(or automate the initial values prior to a formal confirmation by the
site admin).

Next complication -- if you're doing a bulk delete of P objects (using
an admin delete action), all the decisions that had to be done N*M
times now need to be done P*N*M times.

On top of all this, there are cascading problems. For example, lets
say Authors can belong to Teams. If I delete a team, I know I want to
cascade delete all the Authors that belong to that team. But the
Articles associated with members of those teams need to be reassigned.

Then consider the bulk deletion of teams, and so on.

The point I'm trying to make is that there is no single answer that we
can implement that will be right for all business cases. So the best
we can do is to make it *possible* to introduce pre-deletion cleanup
logic, make that interface as clean as we can, and leave it up to the
end user to implement a scheme that is appropriate for their
implementation. These are the 'hooks' that I'm referring to.

Once those hooks are in place, the simple "confirm you want to replace
all instances of X with Y" approach that you're proposing should be a
couple of lines of code, which will probably form the simple example
provided in documentation. However, it will be possible for other
users to implement more complex schemes, as appropriate.

> thanks Russ, but how to involve more people in this discussion, and
> take the discussion to a next step?

A prototype implementation would be a good start. I've been raising
design issues looking entirely from a public API perspective. I
haven't done any exploration of how this would be implemented, so I
have no idea what technical hurdles (if any) exist.

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 at 
http://groups.google.com/group/django-developers?hl=en.