add() and remove() on ManyToManyField with through model
Maybe I'm missing something but I don't see why the lack of of remove() and add() for ManyToManyFields with 'through' model is necessary. For remove, the docs say "The remove method is disabled for similar reasons (to add)" but it's not clear why. All it is required for "beatles.members.remove(john)" to work are the two foreign keys; the extra data of the relationship are not needed. But even for add() the check is restrictive. For one thing, a through model might be defined just to add or override some methods, without any other fields than the two foreign keys. Or, more likely, all additional fields may not require initialisation (nullable, default, auto_now, etc.). These cases would just work without any change in the API. A backwards compatible change to add() would allow even extra required fields: "add(*objs, **relationship_attrs)". Thus the example in the docs: Membership.objects.create(person=paul, group=beatles, date_joined=date(1960, 8, 1), invite_reason= "Wanted to form a band.") could be written as: beatles.members.add(paul, date_joined=date(1960, 8, 1), reason= "Wanted to form a band.") Thoughts ? George -- 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: add() and remove() on ManyToManyField with through model
On Fri, Jun 11, 2010 at 6:47 PM, George Sakkis wrote: > Maybe I'm missing something but I don't see why the lack of of > remove() and add() for ManyToManyFields with 'through' model is > necessary. > > For remove, the docs say "The remove method is disabled for similar > reasons (to add)" but it's not clear why. All it is required for > "beatles.members.remove(john)" to work are the two foreign keys; the > extra data of the relationship are not needed. > > But even for add() the check is restrictive. For one thing, a through > model might be defined just to add or override some methods, without > any other fields than the two foreign keys. Or, more likely, all > additional fields may not require initialisation (nullable, default, > auto_now, etc.). These cases would just work without any change in the > API. A backwards compatible change to add() would allow even extra > required fields: "add(*objs, **relationship_attrs)". Thus the example > in the docs: > > Membership.objects.create(person=paul, group=beatles, > date_joined=date(1960, 8, > 1), > invite_reason= "Wanted to > form a band.") > could be written as: > > beatles.members.add(paul, date_joined=date(1960, 8, 1), reason= > "Wanted to form a band.") > > Thoughts ? This was discussed at the time that m2m-intermediate models were added. If you want some of the history, see the ticket discussion on #6095 (in particular, around here [1]). [1] http://code.djangoproject.com/ticket/6095#comment:31 There are are a couple of issues with the approach you describe. They're not necessarily insurmountable issues, but they were enough of a problem for us to make the decision to punt them until later in the interests of delivering basic m2m-intermediate functionality. Now that we've been living with m2m-intermediates for a while (almost 2 years), the time may be ripe to revisit these dangling issues. If you want to make a proposal in this area, feel free to do so -- just make sure you address the history when you do. It's not necessarily as simple as just adding kwargs to the add() method. For the record, the same approach was also taken for admin handling of m2m intermediates; however, with the refactoring of m2m that occurred in order to support multi-db, those admin issues were resolved. 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.
Session overload
Hi, I am using long living session in the database backend. Because of Robots I am getting a huge amount of sessions. I googled if there is some kind of Session middleware that does user-agent blacklisting and does not create new sessions in the database for Robots accessing the site. I did not find anything. Would this be possible at all? I could think of subclassing django.contrib.sessions.backend.db.SessionStore and only create some kind of in-memory Pseudo Session. I am afraid that I have to override almost all methods of SessionStore for that. Does anyone know of an existing solution for this problem? If not, would my proposed solution be the way to go, or are there better alternatives? Regards, Jan Murre -- 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: Session overload
On Fri, Jun 11, 2010 at 11:41 AM, jjmurre wrote: > Hi, > > I am using long living session in the database backend. Because of > Robots I am getting a huge amount of sessions. I googled if there is > some kind of Session middleware that does user-agent blacklisting and > does not create new sessions in the database for Robots accessing the > site. I did not find anything. Would this be possible at all? > > I could think of subclassing > django.contrib.sessions.backend.db.SessionStore and only create some > kind of in-memory Pseudo Session. I am afraid that I have to override > almost all methods of SessionStore for that. > > Does anyone know of an existing solution for this problem? If not, > would my proposed solution be the way to go, or are there better > alternatives? > > Regards, > > Jan Murre > Subclass django.contrib.sessions.middleware.SessionMiddleware, overriding process_request. Determine whether you should or should not initiate a session from the request object, and if you should, call the super class's process_request method. Replace django.contrib.sessions.middleware.SessionMiddleware in settings.MIDDLEWARE_CLASSES with your replacement one. Simples. Cheers Tom -- 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: add() and remove() on ManyToManyField with through model
On Jun 11, 1:11 pm, Russell Keith-Magee wrote: > On Fri, Jun 11, 2010 at 6:47 PM, George Sakkis > wrote: > > Maybe I'm missing something but I don't see why the lack of of > > remove() and add() for ManyToManyFields with 'through' model is > > necessary. > > > For remove, the docs say "The remove method is disabled for similar > > reasons (to add)" but it's not clear why. All it is required for > > "beatles.members.remove(john)" to work are the two foreign keys; the > > extra data of the relationship are not needed. > > > But even for add() the check is restrictive. For one thing, a through > > model might be defined just to add or override some methods, without > > any other fields than the two foreign keys. Or, more likely, all > > additional fields may not require initialisation (nullable, default, > > auto_now, etc.). These cases would just work without any change in the > > API. A backwards compatible change to add() would allow even extra > > required fields: "add(*objs, **relationship_attrs)". Thus the example > > in the docs: > > > Membership.objects.create(person=paul, group=beatles, > >date_joined=date(1960, 8, > > 1), > >invite_reason= "Wanted to > > form a band.") > > could be written as: > > > beatles.members.add(paul, date_joined=date(1960, 8, 1), reason= > > "Wanted to form a band.") > > > Thoughts ? > > This was discussed at the time that m2m-intermediate models were > added. If you want some of the history, see the ticket discussion on > #6095 (in particular, around here [1]). > > [1]http://code.djangoproject.com/ticket/6095#comment:31 > > There are are a couple of issues with the approach you describe. > They're not necessarily insurmountable issues, but they were enough of > a problem for us to make the decision to punt them until later in the > interests of delivering basic m2m-intermediate functionality. > > Now that we've been living with m2m-intermediates for a while (almost > 2 years), the time may be ripe to revisit these dangling issues. If > you want to make a proposal in this area, feel free to do so -- just > make sure you address the history when you do. It's not necessarily as > simple as just adding kwargs to the add() method. Thanks for the prompt reply! I skimmed through the ticket but I'm not sure I spotted any particularly unsolvable problems. Just to clarify, I am interested in the following three issues, more or less independently from each other: 1) remove(): The only related comment I read in the ticket is "There is an analogous problem with remove - since you can now have multiple relations between objects, a simple remove method is no longer an option.". But remove() is a method of a descriptor referring to a specific m2m relation, so it is clear to which one it refers to. E.g. in your example: a_group.club_membership.remove(a_person) # remove person from club_members a_group.team_membership.remove(a_person) # remove person from team_members. If the issue had to do specifically with the fact that that the same through model (Membership) was used between Group and Person more than once, I am not interested in allowing this; the current validation approach is fine. 2) add() for m2m-intermediates with only null/default/derived extra fields. If I'm reading your comments correctly, you were against adding null=True to fields that are not semantically nullable, just as a workaround for add(). I agree and I'm not suggesting adding nulls or defaults just for the sake of making add() work, but for fields that should accept null or a default regardless, why prevent them ? As for the implementation, I'm not suggesting any 'compile time' validation and introspection; just let any errors happen when add() eventually calls through.create(...). 3) add() for m2m-intermediates with required extra fields. The suggestion in the ticket is to pass an 'extra' dict argument; I'm fine with that instead of passing them as **extra; it has the added benefit it can be used in create() as well (although I'm less interested in allowing create). Fully agree with your comments about not adding more fine-grained, per-object extra arguments (you can always use multiple calls to add()) or an additional "add_extra" method. If there are any other issues I ignored, let me know and I'll be happy to consider them. George -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Imports in the tutorial
On 11/06/2010 03:28, Peter Baumgartner wrote: In my experience, almost every project has domain-specific applications that don't get reused. If you have a reusable app, you bundle it separately (like South). I entirely agree, but there's also a lot of domain-specific apps people make that get used in more than one project. If you're in the business of writing (say) CMS-backed sites, you're going to have a lot of apps matching that pattern, and as far as I'm aware, there's no downside to switching away from having project names in imports. Why do you need to change the Python path at all? Just drop your project on the existing Python path and import from there. This is easy enough with a symlink or better yet give it a setup.py and install it like you would any other Python package. But that doesn't work. Say I have my nice shiny project "andrewblog". I want to deploy a staging version and a live version of this on my server. If I had local imports, I could just put both projects on the python path / install them / egg-link them, or whatever. But because they use module names for imports, if I install one site as a package "andrewblog" and the other as "andrewblog_staging", say, staging is actually going to be running off of the live models, URLs, etc, since it has code that goes "from andrewblog.posts.models import Post". I agree that it is confusing that it will work either way, but I'd argue in favor of using the project name everywhere. It is explicit instead of mucking around with the Python path behind the scenes. Explicitness is good. I like being explicit, that's one of the reasons I love Python. But I'd argue that having to separate installations of the same app because they _have_ to have the same package name involves more python path mucking around than just installing them on the global path with different names. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Imports in the tutorial
On Fri, Jun 11, 2010 at 10:16 AM, Andrew Godwin wrote: >> I agree that it is confusing that it will work either way, but I'd >> argue in favor of using the project name everywhere. It is explicit >> instead of mucking around with the Python path behind the scenes. >> > > Explicitness is good. I like being explicit, that's one of the reasons I > love Python. But I'd argue that having to separate installations of the same > app because they _have_ to have the same package name involves more python > path mucking around than just installing them on the global path with > different names. there's a difference between being explicit and introducing unneeded dependencies. -- Javier -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Query Refactor Status Update
On Fri, Jun 11, 2010 at 12:22 AM, Waldemar Kornewald wrote: > On Thursday, June 10, 2010, Dj Gilcrease wrote: >> Wouldnt an autofield like http://dpaste.com/hold/205665/ work where >> connection.creation.auto_field_base_type is set to int by default in >> django/db/backends/creation.py but could be overridden by an >> individual backend to be str or unicode or whatever? > > That's pretty much how Django-nonrel does it. The problem which > Russell talked about is that some developers seem to do something like > > def myview(request, pk): > try: > query = MyModel.objects.filter(pk=pk) > except ValueError: > # oh no, someone passed a string instead of a number! :( > ... > try: > result = query.get() > except MyModel.DoesNotExist: > ... > > With the poposed AutoField change the exception could not be raised at > query construction time (the first try: block), but at execution time > (the second try: block), so a more flexible AutoField would break the > code above. Though, maybe the exception would become > ObjectDoesNotExist instead of ValueError, so it wouldn't really break > the code above, but it would behave in a different way because the > first except: clause wouldn't be executed, anymore. Russell, please > correct me if you meant something different. No - you've understood me correctly. > So, the question (as far as I understand) is whether the code above is > actually used by so many developers that you could justify making > NoSQL support a second-class citizen. Or, to put a different, but equally melodramatic spin on it: are we going to break backwards compatibility and force an unknown proportion of our existing userbase to go through a painful audit process to identify places where they are relying upon a particular ORM feature? As a project, Django takes backwards compatibility *very* seriously. Our existing user base is just as important as the user base we may acquire as a result of adding new features. We're not going to sacrifice (or massively inconvenience) one user base in order to acquire another. That doesn't mean we can't or won't make changes. However, it does mean that we need to be acutely aware of the impact those changes will have on users, and provide a staged transition plan for users that may be dependent on the old behavior. Thinking aloud, one possible approach to handling this transition might be to use the contents of DATABASES. Any current Django user will have a DATABASES (or DATABASE_ENGINE) setting that describes one or more SQL databases. It won't be until we (officially) add non-SQL databases that this AutoField issue will actually manifest. Therefore, we could inspect the DATABASES list, and if the user has a non-SQL database in their DATABASES list (as identified by some flag in the backend), the behavior of AutoField could change to a 'passthrough' that is validated on the backend. If the user only has SQL backends, the field will behave as it does currently, but raise a PendingDeprecationWarning; over the next couple of releases, this would escalate to a full Warning, before the feature is completely removed. This approach provides the functionality that is required to support non-SQL backends right now, but also provides a long term plan for transitioning users to the new behavior. Existing apps will continue to work, but may break if you use them in a project that utilizes noSQL. However, part of the task of adopting NoSQL in your Django project would be ensuring that all your dependency apps have been updated to be compliant with the new-style AutoField validation behavior. Now - like I said, I'm just thinking aloud here. I haven't fully thought through the consequences of this change. I'm not necessarily advocating it as a viable solution. What I want to point out is that there are ways to accommodate change that don't require us to break backwards compatibility at a single version. Any proposal to modify Django in a backwards incompatible way that *doesn't* have a transition plan is a non-starter. 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: Query Refactor Status Update
On Thu, Jun 10, 2010 at 10:18 PM, Waldemar Kornewald wrote: > On Thu, Jun 10, 2010 at 2:31 PM, Russell Keith-Magee > wrote: >> On Wed, Jun 9, 2010 at 4:25 AM, Waldemar Kornewald >> wrote: >>> By not supporting string-based primary keys the MongoDB and SimpleDB >>> communities will have to maintain their own version of all Django apps >>> which are already App Engine compatible. Also, writing code for >>> MongoDB and SimpleDB and many other backends will become more annoying >>> because you have to explictly specify a NativeAutoField in all of your >>> models. >>> >>> By supporting string-based primary keys many existing Django apps can >>> work unmodified and those that don't work only need a few *trivial* >>> (!) changes which are even backwards-compatible, so SQL code would >>> continue to work and unit tests would still validate. At least the App >>> Engine and MongoDB and SimpleDB communities could easily share the >>> same code because they have very similar query capabilities. Most >>> probably many more backends could join. This is a ***huge*** and very >>> ***cheap*** advantage and we shouldn't just throw it away. >> >> The issue here is what "supporting string-based primary keys" means. >> At present, AutoField.get_prep_value checks that the pk is an integer >> (or None); if it is a string, it is coerced into an integer using >> int(). This is well established and tested behavior, and it's not >> something we can change without violating backwards compatibility. > > The string coercion can be moved down to the backend level, so the > only issue here is the exception raised by int() if the object is a > string which makes this a very similar (if not the same) issue as the > next one. > >> On top of that, the contract for filter et al currently guarantees >> that filter values are validated at time of query construction, not >> when they are executed. Again, this is behavior that we can't change >> without violating backwards compatibility. >> >> From an initial inspection, it appears that you've broken both of >> these conditions in your branch. If I've missed something, feel free >> to set me straight. > > That's right. We believe that the long-term advantages of having a > common AutoField for everyone outweigh the short-term disadvantage of > a few people having to migrate their code. By far not everyone depends > on the current behavior and this wouldn't be the first backwards > incompatible change for Django, so what's the problem with AutoField? > Do you just want to make sure there is no other solution or is > changing AutoField inacceptable, in general? I've commented on this in detail in a separate thread, but the summary: Changing AutoField is possible, but only if there is a transition plan for any user that is relying on the existing behavior. >> I had some brief discussions with Alex about a possible approach that >> involves treating the hashes that many noSQL backends use as key value >> as if they were integers; Alex was going to do some further >> investigation. I'll leave it up to him to report if he has any >> success. > > You mean, converting string-based keys to integers? That would result > in really huge numbers and very ugly URLs. Or did mean something > different? Strictly, the primary key value doesn't have to be converted to integers; they just need to implement __int__(). We were batting around some ideas on IRC about how we might be able to exploit this particular loophole; again, Alex was going to investigate and see what he could come up with. As for ugly URLs -- a 32 character hex digest is a pretty ugly URL, but if that's what Mongos (and others) use as a primary key, then that's what you have to deal with. 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: Imports in the tutorial
On Fri, Jun 11, 2010 at 9:16 AM, Andrew Godwin wrote: > > > On 11/06/2010 03:28, Peter Baumgartner wrote: >> >> In my experience, almost every project has domain-specific >> applications that don't get reused. If you have a reusable app, you >> bundle it separately (like South). >> > > I entirely agree, but there's also a lot of domain-specific apps people make > that get used in more than one project. If you're in the business of writing > (say) CMS-backed sites, you're going to have a lot of apps matching that > pattern, and as far as I'm aware, there's no downside to switching away from > having project names in imports. > >> Why do you need to change the Python path at all? Just drop your >> project on the existing Python path and import from there. This is >> easy enough with a symlink or better yet give it a setup.py and >> install it like you would any other Python package. >> > > But that doesn't work. Say I have my nice shiny project "andrewblog". I want > to deploy a staging version and a live version of this on my server. > > If I had local imports, I could just put both projects on the python path / > install them / egg-link them, or whatever. But because they use module names > for imports, if I install one site as a package "andrewblog" and the other > as "andrewblog_staging", say, staging is actually going to be running off of > the live models, URLs, etc, since it has code that goes "from > andrewblog.posts.models import Post". Why do your two sites need to share the same python path? Virtualenv solves this problem quite gracefully. -- Pete -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Query Refactor Status Update
On Fri, Jun 11, 2010 at 5:25 PM, Russell Keith-Magee wrote: > On Thu, Jun 10, 2010 at 10:18 PM, Waldemar Kornewald > wrote: >> That's right. We believe that the long-term advantages of having a >> common AutoField for everyone outweigh the short-term disadvantage of >> a few people having to migrate their code. By far not everyone depends >> on the current behavior and this wouldn't be the first backwards >> incompatible change for Django, so what's the problem with AutoField? >> Do you just want to make sure there is no other solution or is >> changing AutoField inacceptable, in general? > > I've commented on this in detail in a separate thread, but the > summary: Changing AutoField is possible, but only if there is a > transition plan for any user that is relying on the existing behavior. I've read Django's policy on breaking backwards compatibility and I didn't propose to break compatibility in a single release. I just assumed we'd first discuss if we need to break compatibility and then find out how the transition period should be handled. The transition plan that you proposed sounds pretty reasonable. >> You mean, converting string-based keys to integers? That would result >> in really huge numbers and very ugly URLs. Or did mean something >> different? > > Strictly, the primary key value doesn't have to be converted to > integers; they just need to implement __int__(). We were batting > around some ideas on IRC about how we might be able to exploit this > particular loophole; again, Alex was going to investigate and see what > he could come up with. Hmm, I'm not sure how you want to add __int__() to a pk value passed to a view. In that case you just have a pure string object. Anyway, let's wait for Alex. > As for ugly URLs -- a 32 character hex digest is a pretty ugly URL, > but if that's what Mongos (and others) use as a primary key, then > that's what you have to deal with. Yes, it's still ugly and compared to a hex string a number wouldn't be much longer (I was thinking more in terms of base64 url-safe encoding which would be much shorter than the number representation). Maybe we could also consider converting the pk to a number if we don't find any other solution. It only has the disadvantage that the DB and Django would use different representations of the same primary key which could be annoying during a debug session. Bye, Waldemar Kornewald -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Imports in the tutorial
On 11/06/10 17:00, Peter Baumgartner wrote: > Why do your two sites need to share the same python path? Virtualenv > solves this problem quite gracefully. > They don't have to, but bear in mind that: a) The tutorial is aimed at people new to Django, and often new to Python. Virtualenv isn't even on their radar at this point. b) Bugs from this issue can be really tricky to track down, and I've seen it happen several times on both developer workstations and servers. I'm not saying that removing them is entirely a win, but for the target audience of that document, I really think it's appropriate to teach it from the start. I've seen new Django developers make the mistake of importing from the project name countless times in supposedly-reuseable-internally apps, and I've spent many hours going through with grep and fixing it. The way I see it, if we remove them, the worst bug that could happen is if someone manages to get two different project directories on their python path at the same time (thus the app namespace clashes). Compared to the alternative, and the unlikeliness of this scenario, I really feel it's the best move, unless we try to teach new users about virtualenv, pip, dependency files, and the whole stack that a lot of more advanced Django developers use. We certainly need to think about teaching that stuff - it came up as a topic during djangocon.eu, but I don't think any consensus was reached - but you need to walk before you can run. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
RE: Imports in the tutorial
Speaking as someone who got up to speed on both Django and python in the last year or so, I'd have loved to have been pointed to virtualenv, pip and the stack early on in the learning process. I will say that I am an experienced developer, so I was used to these kinds of technologies and wanting them as I went through, so I'm not a good reference point as a total newb. I took a roundabout route, but I got there eventually. Just a reference point. Cheers, gabe -Original Message- From: django-developers@googlegroups.com [mailto:django-develop...@googlegroups.com] On Behalf Of Andrew Godwin Sent: Friday, June 11, 2010 9:11 AM To: django-developers@googlegroups.com Subject: Re: Imports in the tutorial Compared to the alternative, and the unlikeliness of this scenario, I really feel it's the best move, unless we try to teach new users about virtualenv, pip, dependency files, and the whole stack that a lot of more advanced Django developers use. We certainly need to think about teaching that stuff - it came up as a topic during djangocon.eu, but I don't think any consensus was reached - but you need to walk before you can run. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Imports in the tutorial
On Fri, Jun 11, 2010 at 1:21 AM, Andrew Godwin wrote: > Hi all, > > I noticed today that the tutorial still does imports like "from > mysite.polls.models import Poll", and URLs like "(r'^polls/$', > 'mysite.polls.views.index')". It also says "coming soon" at the end of tutorial 4. It has said that for a while now :-) You're not missing anything specific -- it's really just a matter of time. Good documentation take time to write; doubly so for good tutorials. The issue you raise - that the current tutorial is exclusively "app inside project" has been raised as a ticket more times than I care to count. I would certainly welcome anybody that wants to fix it so that it never gets raised again :-) It's not as simple as just rewriting the existing 4 steps of the tutorial, though. As Peter points out, there is a legitimate use case for "project-specific apps" -- as a way of namespacing apps that truly are project specific. Where the current tutorial fails is that it doesn't take the next step by and demonstrate how (and when) an app can (or should) be broken out from the project structure. The simple step of making the 'poll' a truly reusable app, and explaining why this is a good idea, would be a great tutorial 5 IMHO. Part of this tutorial may be to point out exactly how unnecessary the 'project' directory really is in the purist sense -- at the end of the day, all you really need is a settings file and a bunch of apps in your PYTHONPATH. 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: Class based generic views in 1.3?
On Fri, Jun 4, 2010 at 1:53 PM, Roald wrote: > class my_view(HttpResponse): > __metaclass__ = ABCMeta > > def __init__(self, *args, **kwargs): > print 'init my_view' > > def __new__(cls, *args, **kwargs): > if some_condition(): > return some_view(*args, **kwargs) > elif other_condition(): > return some_standard_response(*args, **kwargs) > else: > ... > return object.__new__(cls) > > > my_view.register(some_view) > my_view.register(some_standard_response) > > > This (or something like it) seems to be able to take the best of the > __new__ and __init__ options. Uhm... guys, Maybe something simpler? 8< from threading import local, Thread class View(object): _child = local() def __new__(cls, *args, **kwargs): existing = hasattr(cls._child, 'instance') if not existing: print 'first time in this thread' cls._child.instance = super(View, cls).__new__(cls, *args, **kwargs) return cls._child.instance def __call__(self, foo): print 'call', id(self), foo return 'bar' test = View() test(1) test = View() test(2) test = View() test(3) class TestThread(Thread): def run(self): test = View() test(4) t = TestThread() t.setDaemon(True) t.start() t.join() test = View() test(5) 8< Try it now, tests itself. -- Patryk Zawadzki -- 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 generic views in 1.3?
On Fri, Jun 11, 2010 at 7:34 PM, Patryk Zawadzki wrote:
> Maybe something simpler?
Actually you might want to have a couple of instances with different
__init__ params:
8<
from threading import local, Thread
class View(object):
_child = local()
def __new__(cls, *args, **kwargs):
if not hasattr(cls._child, 'dict'):
cls._child.dict = {}
param_hash = (args, tuple(kwargs.items()))
existing = cls._child.dict.get(param_hash, None)
if not existing:
print 'first time in this thread with args', param_hash
cls._child.dict[param_hash] = super(View, cls).__new__(cls)
return cls._child.dict[param_hash]
def __call__(self, foo):
print 'call', id(self), foo
return 'bar'
--
Patryk Zawadzki
--
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.
URLValidator on urls without protocol
hello, something just came up on #django and I think it's worth asking here; turns out current URLValidator http://code.djangoproject.com/browser/django/tags/releases/1.2.1/django/core/validators.py#L41forbids urls without protocol however the URLField that uses it tries to add a default "http://"; in case it's missing http://code.djangoproject.com/browser/django/tags/releases/1.2.1/django/forms/fields.py#L526 the fix is trivial, just change the regex to make the first part optional but I'm not sure if you'll prefer to simply drop that functionality on the widget and reject all those urls to retain compatibility. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Imports in the tutorial
On 11/06/2010 17:38, Russell Keith-Magee wrote: You're not missing anything specific -- it's really just a matter of time. Good documentation take time to write; doubly so for good tutorials. The issue you raise - that the current tutorial is exclusively "app inside project" has been raised as a ticket more times than I care to count. I would certainly welcome anybody that wants to fix it so that it never gets raised again :-) It's not as simple as just rewriting the existing 4 steps of the tutorial, though. As Peter points out, there is a legitimate use case for "project-specific apps" -- as a way of namespacing apps that truly are project specific. Where the current tutorial fails is that it doesn't take the next step by and demonstrate how (and when) an app can (or should) be broken out from the project structure. The simple step of making the 'poll' a truly reusable app, and explaining why this is a good idea, would be a great tutorial 5 IMHO. Part of this tutorial may be to point out exactly how unnecessary the 'project' directory really is in the purist sense -- at the end of the day, all you really need is a settings file and a bunch of apps in your PYTHONPATH. Right, I remember the whole "Part 5" and virtualenv thing being discussed before. If we can come to some consensus on what should go in there, I'm happy to write more tutorial parts/edit the current ones and have someone who doesn't, write, like they, speak, go over it in an editorial role. Problem is there's several things that could go in a part 5 (in addition to all of those there currently), like: - Making your apps reuseable (so things like removing project name imports, adding a setup.py, general python packaging theory) - Using virtualenv to run multiple copies of apps/projects/Django side-by-side on a development box - Basic deployment onto servers (this is kind of covered elsewhere, so perhaps just a pointer, or refine those docs with more common pitfalls) There's also the risk of guiding people down too narrow a path. I'm really not very good at deciding the order and layout of documentation, just at generating it in large amounts (see the mass of mostly unnavigable words that is the South docs). Andrew -- 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: URLValidator on urls without protocol
looking at the order in which the methods are called on the Field class it seems the default "http://"; is added before the validator gets called so it should work as expected, don't know where the error in validation was coming from. On Fri, Jun 11, 2010 at 2:28 PM, Michael Cetrulo wrote: > hello, something just came up on #django and I think it's worth asking > here; turns out current URLValidator > http://code.djangoproject.com/browser/django/tags/releases/1.2.1/django/core/validators.py#L41forbids > urls without protocol however the URLField that uses it tries to add > a default "http://"; in case it's missing > http://code.djangoproject.com/browser/django/tags/releases/1.2.1/django/forms/fields.py#L526 > > the fix is trivial, just change the regex to make the first part optional > but I'm not sure if you'll prefer to simply drop that functionality on the > widget and reject all those urls to retain compatibility. > -- 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: Session overload
On Fri, Jun 11, 2010 at 3:13 PM, Tom Evans wrote: > On Fri, Jun 11, 2010 at 11:41 AM, jjmurre wrote: >> Hi, >> >> I am using long living session in the database backend. Because of >> Robots I am getting a huge amount of sessions. I googled if there is >> some kind of Session middleware that does user-agent blacklisting and >> does not create new sessions in the database for Robots accessing the >> site. I did not find anything. Would this be possible at all? >> >> I could think of subclassing >> django.contrib.sessions.backend.db.SessionStore and only create some >> kind of in-memory Pseudo Session. I am afraid that I have to override >> almost all methods of SessionStore for that. >> >> Does anyone know of an existing solution for this problem? If not, >> would my proposed solution be the way to go, or are there better >> alternatives? >> >> Regards, >> >> Jan Murre >> > > Subclass django.contrib.sessions.middleware.SessionMiddleware, > overriding process_request. > Determine whether you should or should not initiate a session from the > request object, and if you should, call the super class's > process_request method. > Replace django.contrib.sessions.middleware.SessionMiddleware in > settings.MIDDLEWARE_CLASSES with your replacement one. > > Simples. > > Cheers > > Tom > Hi Tom, Thanx for your help. That sounds like a very good approach. I assume I have to put some dict-like object on the request to avoid all kinds of attribute errors? Regards, Jan -- 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: URLValidator on urls without protocol
turns out there is a problem, the field looks for "://" anywhere on the
value but according to the RFC the colon is allowed on paths, so an url like
'www.example.com/://' should validate and it fails:
Python 2.6.4 (r264:75706, Jan 25 2010, 08:55:26)
[GCC 4.4.2 20091208 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import django
>>> django.VERSION
(1, 2, 1, 'final', 0)
>>> from django import forms
>>> class MyForm(forms.Form):
... url = forms.URLField()
...
>>> form = MyForm({'url': 'www.example.com/http://foo/bar/'})
>>> form.is_valid()
False
http://www.rfc-ref.org/RFC-TEXTS/3986/chapter3.html#sub3
On Fri, Jun 11, 2010 at 3:21 PM, Michael Cetrulo wrote:
> looking at the order in which the methods are called on the Field class it
> seems the default "http://"; is added before the validator gets called so
> it should work as expected, don't know where the error in validation was
> coming from.
>
>
> On Fri, Jun 11, 2010 at 2:28 PM, Michael Cetrulo wrote:
>
>> hello, something just came up on #django and I think it's worth asking
>> here; turns out current URLValidator
>> http://code.djangoproject.com/browser/django/tags/releases/1.2.1/django/core/validators.py#L41forbids
>> urls without protocol however the URLField that uses it tries to add
>> a default "http://"; in case it's missing
>> http://code.djangoproject.com/browser/django/tags/releases/1.2.1/django/forms/fields.py#L526
>>
>> the fix is trivial, just change the regex to make the first part optional
>> but I'm not sure if you'll prefer to simply drop that functionality on the
>> widget and reject all those urls to retain compatibility.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Django Related-Object Links in Admin
>> * Permissions - from my initial inspection, it isn't obvious to me >> that you are honoring (and/or testing that you are honoring) >> permissions. If I don't have permission to edit an object, I shouldn't >> get an edit link. Given the addition in 1.2 of object-level >> permissions, this means permissions need to be per-object. Have I >> missed something in my hasty patch read? > > Correct; no permissions checking is performed at present. In some > places checking would be almost impossible given the current code > architecture, so I had hoped to avoid it if possible. This was one of > the main points I wanted feedback on. Here is a more detailed explanation of why permission checking has been omitted for now: * The "add-another" link (green plus) next to ForeignKey widgets is appended to the HTML output in the render() method. This currently has no access to the User, so cannot determine permissions. The "add-another" link (and new "edit" link) will therefore be displayed regardless of the current user's add/change permissions for the related object. This should certainly be dealt with, but this ticket does not appear to the the appropriate place to do so. Ticket #1035 [1] addresses this issue. * The "edit separately" links on inlines could perform checking using a templatetag, perhaps. Again, however, I'm not sure that this is the place to deal with this as larger issues exist -- currently a user can add/change inlines even if they do not possess permissions for the inline model. Ticket #8060 [2] addresses this issue. So the current patch for #13163 and #13165 [3] seems to solve the issues in a manner which fits with the rest of the admin interface as it currently stands. Permission issues should certainly be dealt with, but separately I believe. I think [3] could be committed as is (pending review), and permission controls added as the other tickets are resolved. Currently all this means is that people might see an edit link, click on it, then get a "permission denied" message -- though in the relatively rare cases where a related object is registered in the same admin site but the user doesn't have permission to change it. IMHO the UX improvements in [3] are worth getting on board ASAP. Simon [1] http://code.djangoproject.com/ticket/1035 [2] http://code.djangoproject.com/ticket/8060 [3] http://code.djangoproject.com/attachment/ticket/13163/combined_13163_13165.diff -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Imports in the tutorial
On Saturday, June 12, 2010, Andrew Godwin wrote: > > > On 11/06/2010 17:38, Russell Keith-Magee wrote: > > You're not missing anything specific -- it's really just a matter of > time. Good documentation take time to write; doubly so for good > tutorials. > > The issue you raise - that the current tutorial is exclusively "app > inside project" has been raised as a ticket more times than I care to > count. I would certainly welcome anybody that wants to fix it so that > it never gets raised again :-) > > It's not as simple as just rewriting the existing 4 steps of the > tutorial, though. As Peter points out, there is a legitimate use case > for "project-specific apps" -- as a way of namespacing apps that truly > are project specific. > > Where the current tutorial fails is that it doesn't take the next step > by and demonstrate how (and when) an app can (or should) be broken out > from the project structure. The simple step of making the 'poll' a > truly reusable app, and explaining why this is a good idea, would be a > great tutorial 5 IMHO. Part of this tutorial may be to point out > exactly how unnecessary the 'project' directory really is in the > purist sense -- at the end of the day, all you really need is a > settings file and a bunch of apps in your PYTHONPATH. > > > > Right, I remember the whole "Part 5" and virtualenv thing being discussed > before. If we can come to some consensus on what should go in there, I'm > happy to write more tutorial parts/edit the current ones and have someone who > doesn't, write, like they, speak, go over it in an editorial role. What - very very quickly? I don't see the problem :-) > Problem is there's several things that could go in a part 5 (in addition to > all of those there currently), like: > > - Making your apps reuseable (so things like removing project name imports, > adding a setup.py, general python packaging theory) > - Using virtualenv to run multiple copies of apps/projects/Django > side-by-side on a development box > - Basic deployment onto servers (this is kind of covered elsewhere, so > perhaps just a pointer, or refine those docs with more common pitfalls) That sounds like three potential tutorials to me. Better get your pencil nice and sharp :-) > There's also the risk of guiding people down too narrow a path. I'm really > not very good at deciding the order and layout of documentation, just at > generating it in large amounts (see the mass of mostly unnavigable words that > is the South docs). Honestly - getting a good first draft is the hardest part. Working out a good example, working out a seizable order for presentation within he tutorial, and getting even a rough first cut at the text is the biggest hurdle. Once we have that, it's relatively simple to knock a draft into shape and fit it into a bigger picture. 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 Related-Object Links in Admin
Sent from my iPad On 09/06/2010, at 8:33 PM, Simon Meers wrote: >> The demo screenshots you provide certainly look good to me; I haven't >> done a full teardown on the patch, but a from a quick glance it >> certainly looks promising. > > Thanks for your response Russ. > >> * Why allow edit links on a readonly field? This seems a little >> redundant to me? > > Because whilst the field on that model might be read-only, the related > object itself is not necessarily. In fact in most cases I've found > that this is the case. OK - makes sense. >> * On the edit link for ForeignKey (localhost:8000 in your example), >> I'd be inclined to stick to just "edit", not "edit " -- that >> seems more consistent with the other edit links you have provided. > > But then if you select a different object, "edit" looks like it refers > to the selected one instead of the original. I could have used > JavaScript here to select the dynamically chosen object, but in the > absence of a popup link this would be pointless -- you choose a > different ForeignKey value, then leave the page to edit it thinking > you've saved the value... Hrm. So this means that if I change the FK from John Smith to Bob Jones, the link continue to be a link to John? While I can see why its implemented like this, it seems less than ideal UI to me. > >> * In the case of raw-id fields and inlines, is there any reason why >> the edit link is separate text, rather than the object name itself >> being the link? (ie., rather than "John smith ", why >> not just ""? > > Yes; because you're already editing John smith, but if you want to > edit him separately you can go elsewhere to do so with a (probably > more detailed) dedicated form. I can see your point. I'd be interested to get some input from someone with some UX credentials on this one. >> * Permissions - from my initial inspection, it isn't obvious to me >> that you are honoring (and/or testing that you are honoring) >> permissions. If I don't have permission to edit an object, I shouldn't >> get an edit link. Given the addition in 1.2 of object-level >> permissions, this means permissions need to be per-object. Have I >> missed something in my hasty patch read? > > Correct; no permissions checking is performed at present. In some > places checking would be almost impossible given the current code > architecture, so I had hoped to avoid it if possible. This was one of > the main points I wanted feedback on. I'll respond to this on your follow up email. 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 Related-Object Links in Admin
Sent from my iPad On 12/06/2010, at 7:15 AM, Simon Meers wrote: >>> * Permissions - from my initial inspection, it isn't obvious to me >>> that you are honoring (and/or testing that you are honoring) >>> permissions. If I don't have permission to edit an object, I shouldn't >>> get an edit link. Given the addition in 1.2 of object-level >>> permissions, this means permissions need to be per-object. Have I >>> missed something in my hasty patch read? >> >> Correct; no permissions checking is performed at present. In some >> places checking would be almost impossible given the current code >> architecture, so I had hoped to avoid it if possible. This was one of >> the main points I wanted feedback on. > > Here is a more detailed explanation of why permission checking has > been omitted for now: > > * The "add-another" link (green plus) next to ForeignKey widgets is > appended to the HTML output in the render() method. This currently has > no access to the User, so cannot determine permissions. The > "add-another" link (and new "edit" link) will therefore be displayed > regardless of the current user's add/change permissions for the > related object. This should certainly be dealt with, but this ticket > does not appear to the the appropriate place to do so. Ticket #1035 > [1] addresses this issue. > > * The "edit separately" links on inlines could perform checking using > a templatetag, perhaps. Again, however, I'm not sure that this is the > place to deal with this as larger issues exist -- currently a user can > add/change inlines even if they do not possess permissions for the > inline model. Ticket #8060 [2] addresses this issue. > > So the current patch for #13163 and #13165 [3] seems to solve the > issues in a manner which fits with the rest of the admin interface as > it currently stands. Permission issues should certainly be dealt with, > but separately I believe. I think [3] could be committed as is > (pending review), and permission controls added as the other tickets > are resolved. Currently all this means is that people might see an > edit link, click on it, then get a "permission denied" message -- > though in the relatively rare cases where a related object is > registered in the same admin site but the user doesn't have permission > to change it. My perspective is the other way around. We already have permission problems, which have been exacerbated by the introduction of row-based permission hooks. IMHO, before we start adding extra entry points where permissions can be wrong, we should get our house in order. I appreciate that this is an impediment to you getting your changes into trunk, but personally, I'd rather see less bugs (especially when those bugs relate to something as important as permissions) than more features. > IMHO the UX improvements in [3] are worth getting on board ASAP. No argument from me on this - absent of other problems, they strike me as worthwhile changes. I just think we should fix the other problems first. > 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.
