Re: Admin interface not preventing simultaneous editing of the same record
On Tue, Aug 11, 2009 at 11:06 PM, Russell Keith-Magee wrote: > > On Wed, Aug 12, 2009 at 10:55 AM, David wrote: >> >> >> >> On Aug 11, 10:29 pm, Russell Keith-Magee >> wrote: >> >>> There are any number of ways to solve this problem by adding a field >>> to the model (autofield with an 'edit number', timestamp tracking last >>> edit time etc). However, these aren't really candidates for a general >>> solution. >> It didn't occur to me before, but would the History mechanism be any >> use here? It must already be tracking edits. > > An interesting thought. I can't think of any obvious technical reason > that the admin Log combined with a timestamp on form submission > couldn't be used. You would need to dig into specifics to see if there > are any complications, but this is certainly worth looking into. > > This would fit into the same camp as the checksum solution - it would > tell you that a concurrent edit has occurred, but wouldn't tell you > how to resolve the concurrent edit. > > Another cause for hesitation is that it would be an admin-specific > solution to the problem. A generic solution that would work for all > ModelForms would be nice if it is possible. However, a working > solution in admin would be better than a theoretical but non-existent > solution in forms. > > Yours, > Russ Magee %-) > > > > The problem with anything relying on AdminLog is it doesn't work if something is changed outside the admin. Personally I think including a JSON dump of the model with the page is the easiest solution, but I could be convinced otherwise. 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-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: Form.Widgets use of Super (of lack there of)?
On Wed, Aug 12, 2009 at 10:19 AM, Joshua Russo wrote: > Why is it that Super is only used sometimes in the __init__ methods of the > existing widgets? Is this by design? I thought that if you used Super > anywhere you had to use it everywhere, otherwise the one place you do use it > wouldn't behave the way you anticipate. That is, if anyone ever uses > multiple inheritance and Super is used sporadically the chain will break at > the first non-existing Super call. > Here is where I'm seeing it missing: > Widget (this is really the biggest problem it seems) > Textarea > Should I create a ticket with the Super calls added to these two? > > > I can't off the top of my head think of a reason for the lack of super() calls, so yes please do file a bug. 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-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 -~--~~~~--~~--~--~---
[GSOC] Final Multi-DB status Update
Hey all, It seems GSOC has finally come to a close and so I'm giving my final status update as a part of GSOC (but I'm not going anywhere!). When we last left off I had just gotten Oracle support working, however after reviewing with Russ we agreed that the solution was a good bit too hacky, and the real root of the problem was that the Query class has 2 functions, one to record information and build a Pythonic representation of a Query, which is the same for all SQL backends, as well as to actually generate SQL from this representation, which is different in the case of Oracle and others. Therefore the solution is to actually split these up into separate classes, so we can swap out SQL generators without needing to care about the data collector. In short that's what I've been working on. Unfortunately this isn't done at the time of writing (and the end of GSOC), however as I said the code basically works now, it's just not in a form that would end up back in Django. But, as I said, I'm not going anywhere. I'm going to continue to work on this problem, and I'll continue to checkin with django-developers as design decisions and complications come up. For now, thanks for all the useful ideas, constructive criticism, and words of encouragement django-developers has provided as I've worked on this. 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-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: Proposal: JS library in admin and tools
On Tue, Aug 18, 2009 at 12:49 PM, David Zhou wrote: > > On Tue, Aug 18, 2009 at 1:35 PM, Yuri Baburov wrote: >> >> In example, I want some django 3rd-party or contrib package with >> autocomplete fields, ajax validation, ajax form sending and inline >> property editing. >> I want to be able to integrate it into admin interface and overall >> interface in painless and fast way. >> >> What do you suggest me to do? >> How do you see further django-and-js-related infrastructure in future? > > What a 3rd-party chooses to use to accomplish functionality is up to > them. jQuery, plus most other libraries, have the ability to operate > in a mode that doesn't cause conflicts with other libraries. As long > as the 3rd-party Django app properly uses those features of the JS > lib, this isn't an issue. > > That way, you can you whatever 3rd party app you want, and not have to > worry about what javascript framework they may or may not have used. > > Integration to the admin can be normal via the normal avenues of admin > customization -- namely, adding in your own forms, templates, and > views. I'm not sure I see how what JS library is used to do things > like AJAX is related. > > -- dz > > > > I'll take a Jacob's comment a step further and say that I personally am opposed to Django using an external JS framework for even the admin. My reason for this is that it restricts the ability of people to contribute to Django. If Django's admin uses jQuery and I know Mootools then I have to learn something new to contribute, but if it's "vanilla" JS then I can dive right it, regardless of what framework I come from (to the people leaping up to say that it's possible to use jQuery/Mootools/PonyJS/whatever without really knowing Javascript I submit to you that that is no less frightening then someone who thinks they know Django without knowing Python). 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-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: Proposal: JS library in admin and tools
On Tue, Aug 18, 2009 at 2:29 PM, Jacob Kaplan-Moss wrote: > > On Tue, Aug 18, 2009 at 2:04 PM, Alex Gaynor wrote: >> I'll take a Jacob's comment a step further and say that I personally >> am opposed to Django using an external JS framework for even the >> admin. My reason for this is that it restricts the ability of people >> to contribute to Django. > > Heh. > > Well, then let's table this discussion for when I propose merging > admin-ui to trunk. Let's not get into a hypothetical argument when > there's a perfectly good concrete one just down the road! > > Putting-on-my-flame-proof-pants-ly yours, > > Jacob > > > > Fair enough :) 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-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: Final Multi-DB status Update
he
> reverse relations. At least here, since I'm working with a queryset,
> I can apply a 'using' clause. So imagining I had a category object
> and wanted to follow it to products, I could something like this:
>
> prds = my_category.product_ref_set.using('c5').all()
>
> Of course, trying to use this in a template still falls short since I
> can't pass a parameter to a function in a template.
>
> I want a Pony:
>
> A great way to fix the above would be to have objects and querysets
> 'remember' where they originated from and apply it forward to any
> requests to related objects or reverse relation lookups. So if I did
> this query:
>
> prds = Products.objects.using('c5').all()
>
> Anytime I reference a product in the prds queryset, it knows it came
> from c5 so all related look ups aim at that DB. Now when I do things
> like:
>
> cat = prds[0].category_ref
>
> Django should know that 'prds' was generated from looking at db c5 and
> it should attempt to look up relationships there first. The reverse
> API should also be available somehow so I can override where a foriegn
> key lookup is done (much like I can already do on reverse look ups
> with an extra 'where' clause).
>
This idea sort of appeals to me, but I fear there are some edge cases
who's behavior I'd want to figure out first. For example, let's say I
have a model with Meta.using = 'db1' and a 2nd model with Meta.using =
'db2'. When I try to access a foreignkey relation from something on
Model1 to Model2, which DB should it use, the one it came from, or the
default for Model2?
> One more pony request: I should be able to spec a 'using' in any of
> the short cut functions too ... like get_object_or_404 (you may have
> already done this).
>
I'd prefer not to alter get_object_or_404 (or similar helpers),
however don't forget, in addition to Models get_object_or_404 can take
a QuerySet, so you can do
get_object_or_404(MyModel.objects.using('db2'), pk=pk)
And it'll do what you want :)
> Regardless of your current status with the branch, I fully intend to
> keep on using this code. Luckily, we're all mysql based here so I
> don't have to worry about the custom back end stuff :) Thanks again
> for your effort this summer Alex!
>
Great to hear!
> Jon.
>
> On Aug 18, 3:24 am, Alex Gaynor wrote:
>> Hey all,
>>
>> It seems GSOC has finally come to a close and so I'm giving my final
>> status update as a part of GSOC (but I'm not going anywhere!). When
>> we last left off I had just gotten Oracle support working, however
>> after reviewing with Russ we agreed that the solution was a good bit
>> too hacky, and the real root of the problem was that the Query class
>> has 2 functions, one to record information and build a Pythonic
>> representation of a Query, which is the same for all SQL backends, as
>> well as to actually generate SQL from this representation, which is
>> different in the case of Oracle and others. Therefore the solution is
>> to actually split these up into separate classes, so we can swap out
>> SQL generators without needing to care about the data collector. In
>> short that's what I've been working on. Unfortunately this isn't done
>> at the time of writing (and the end of GSOC), however as I said the
>> code basically works now, it's just not in a form that would end up
>> back in Django. But, as I said, I'm not going anywhere. I'm going to
>> continue to work on this problem, and I'll continue to checkin with
>> django-developers as design decisions and complications come up.
>>
>> For now, thanks for all the useful ideas, constructive criticism, and
>> words of encouragement django-developers has provided as I've worked
>> on this.
>>
>> 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
> >
>
If anyone has any thoughts on the above "corner case" of that possible
API, or on any part of the idea of remembering where on object comes
from (this would also be true for saving and deleting I think), I'd
love to hear them.
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-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: On returning appropriate subclass instances when querying a model with subclasses
On Tue, Aug 25, 2009 at 10:41 AM, Carl Meyer wrote: > > > > On Aug 23, 9:14 pm, Andrea Zilio wrote: >> So the answer to the question "Can I get the right instances with one >> single and only DB query" seems to be: >> "No, you cannot do so without touching the Django orm code". >> >> Am I right? > > Actually, I think the ORM's extensibility mechanisms are sufficient > that you could provide your QuerySet.select_subclasses() method, which > would perform a single query with n LEFT JOIN's, with custom QuerySet/ > Query subclasses. Writing it would certainly require a non-trivial > level of familiarity with the ORM internals, and you might have to use > private APIs - but I don't think you'd have to modify Django code. > > Carl > > > Actually there's already a ticket to cover the ability to do that type of joining. Ticket 7270 works to add select_related support to reverse 1-1 relations, which is all that inheritance is. 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-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: contrib.admindocs need some love.
On Thu, Aug 27, 2009 at 4:03 PM, Justin Lilly wrote: > Hey guys. > > I started writing some docs for another developer today and hit a few > issues with admindocs that I plan on sprinting on for DjangoCon. I'm > hoping anyone else with complaints / ideas will voice up, though my main > impetus for the post is to announce that I'm going to do it so I > can't back out. ;) > > Things I plan to address: > > 1. No tests. > 2. No docs. > 3. You can't seem to cross-link to views without the link being > app.package.func . I'd like to see it at least configurable. I've actually got a patch that fixes this on my github django repo in the "admindocs" branch. > 4. ManyToManyFields don't show up. > I don't see this problem, for example User/Group show the relationship in both directions correctly, since you clearly don't see it there's probably some more debugging work needed here to figure it all out. > There's not a ton there, but worth sprinting on, imo. Any other ideas or > changes you'd like to see in admindocs that I might be able to work on? > Shout them out. > > -justin > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFKluajbdUY9pLj0/0RA97fAKCKqGSYv9tQacnnlGevWlTxVxly3QCdHZ4H > amfr89aN68C3xEvqCi1Cy/A= > =xrrK > -END PGP SIGNATURE- > > 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-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: Time frame for GSoC projects integration
On Fri, Aug 28, 2009 at 6:17 PM, Yuri Baburov wrote: > > On Sat, Aug 29, 2009 at 2:35 AM, James Bennett wrote: >> >> On Fri, Aug 28, 2009 at 10:09 AM, Yuri Baburov wrote: >>> but could anyone please tell me what's planned time frame for GSoC >>> projects integration into Django if there's any. >> >> There is no timeline I'm aware of. And, personally, I don't think >> there's a need for any sort of special process: these are pieces of >> work which can be proposed for inclusion in Django just like anything >> else. > > But who will propose these pieces and when? > Are they ready for inclusion? > Can I propose them for inclusion? > > I just don't understand who should do what right now, and if people do > understand their, ehm, responsibilities and the whole process :) > > Just it seems I'm one of the persons interested in their soonest > successful inclusion. > > -- > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, > MSN: bu...@live.com > > > > I imagine the projects will be proposed by the student and mentor responsible for them. Even for the projects that were very successful and got most (or all) of their work done there's probably stuff to be done to make it Django core ready. 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-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: App Engine support
On Sun, Aug 30, 2009 at 11:06 AM, Waldemar Kornewald wrote: > > On Aug 30, 3:50 pm, Andi Albrecht > wrote: >> No need to hurry. I'll keep this in sync with the trunk - should be >> really unproblematic :) > > I'm not really doing this just for fun, so I'd rather get it done > faster. ;) > >> Regarding the App Engine backend: I have some minimal code here for >> the database backend. Currently it does nothing useful but it provides >> at least the backed so that it is importable in the shell. >> Andy, are you working on this too? Maybe you've got more on your desk >> than just a database backend stub... > > Nice. If you already have commit access you could push it into the > backend repo. Please create a separate package within the repo because > we'll have multiple backends in there (email, DB, maybe sessions, > maybe memcache). BTW, did you have a look at the DB backend in app- > engine-patch? That already provides a lot of important features like > creating a test DB, managing different DB files per appid, supporting > remote DB access, etc. > > In general, it's always a good idea to first look at the app-engine- > patch source (including the patched Django repository), so you don't > duplicate code unnecessarily. > >> BTW, what would be a good name for this backend? "appengine", or is >> "bigtable" more appropriate? > > I'd say "appengine" because we're not really using BigTable directly > (the App Engine datastore is built on top of BigTable, but they're not > the same). > > Bye, > Waldemar Kornewald > > > I'd be -1 on having a seperate, restricted API. There is, IMO, no reason to have more than one API, any sort of restricted system should come in the form of documentation saying what the minimum functionality needed for a database backend to support Django's various features + the backend throwing exceptions for unsupported operations. 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-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: backend query_class() question
On Wed, Sep 2, 2009 at 10:47 AM, Russell Keith-Magee wrote: > > On Wed, Sep 2, 2009 at 2:44 PM, Waldemar Kornewald > wrote: >> >> Hi, >> why does the backend's query_class() function get the default query >> class as its parameter? Can't the backend just import BaseQuery? I'm >> asking because with different BaseQuery implementations (for SQL and >> non-SQL) there is no real default query class, anymore. > > I'll be the first to admit that the Query/BaseQuery/query_class() > infrastruture is a little bit messy. > > The query_class() method on the backend exists for the benefit of > Oracle. Oracle requires special handling for queries that involve > LIMIT and OFFSET, as well as some custom type conversions. > > The reason you pass in the base class is because the Oracle backend > takes the BaseQuery class, and constructs a subclass of BaseQuery that > has the Oracle-specific modifications. > > This can't be done using simple subclassing because the InsertQuery, > DeleteQuery et al are themselves subclasses of Query - or, in the case > of Oracle, the generated Oracle subclass. You'll note that the only > place that query_class() is used is at the bottom of sql/query.py, > where the call to query_class is used to determine whether BaseQuery > or a backend-generated query_class() will be used as sql.Query. > > This is an area of the code that is currently causing difficulty for > the multi-database project. Obviously, this is also an area that > affects non-SQL backends. If you have any particular requirements or > design suggestions here, it would be helpful to know what they are. I > was hoping to dig into this during the sprints at DjangoCon when > Malcolm and I will be in the same room; the more background and > requirements we have, the better. > > Yours, > Russ Magee %-) > > > > As Russ says this is something causing problems for multi-db. I think it's important to recognize that there are 2 "types" of backends, something like Oracle/DB2/MsSQL that is fundamentally the same architecture as the existing SQL backend but just needs slightly different handling, and something like SimpleDB/GAE that's a different model entirely. In my multi-db branch I've introduced the concept of a SQL compiler. And this works for the cases where the intermediate storage is the same as the builtin Query class's, however if you want to store data differently than Query then interoperability in a mulit-db enviroment becomes more difficult. Like Russ said this is something that we'll be spending time discussing at DjangoCon. 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-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: SoC merge plans?
Hey! On Sat, Sep 12, 2009 at 6:40 AM, Jacob Kaplan-Moss wrote: > > Hi folks -- > > I'd like to start thinking about merging the SoC branches. As far as I > can tell we've got solid, worth-merging work out of all six of 'em -- > WOOHOO! -- so let's cracking getting this stuff to trunk so people can > play with it. > > I'd like to ask each mentor/student pair to give me a bit of information: > > * A quick summary (more for the list than for me) of what new things > are on the branch, and give some instructions to people wanting to > review your code. > Multiple database support is in my branch :) > * A detailed explanation of *any* backwards-incompatible changes > merging your branch would make. > If you touch anything internal to Query, it may break. > * Are all the technical aspects of your house in order? Is what's on > the branch at about the same level as we'd require from a patch (tests > passing, APIs complete, documentation included)? If not, what's left > to be done in this department? > We have one last DDN issue to solve and some smaller technical stuff to work on, Russ and I will be working on this stuff today hopefully. > * Is it going to be better to merge bits off the branch piecemeal, or > should we plan to merge the whole dang thing? > I technically have 2 branches. One that does multiple database, and one that refactors many to many relations. The latter should be merged before the former. > * Are there any other branches you're worried about comparability > with? Or any other sort of sequencing concerns we should take into > account? > > I'm going to be reviewing the branches looking for these sorts of > things, and I'm going to try to work up a merge plan over the next > week or so. > > Jacob > > > > 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-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: Final Multi-DB status Update
On Mon, Sep 14, 2009 at 12:49 PM, JL wrote:
>
> Russell Said:
>
> "I'm yet to be convinced that `Meta: using` is actually a good thing.
> IMHO, it's the very model of a setting that makes it impossible to
> re-use your application. The setting will probably survive into the
> final version, but I suspect we need a much better mechanism than
> `Meta: using` for most common use cases. Again, this comes back to my
> comment on your original point 2"
>
> Piling back onto this a little late but I'm definitely a +1 here.
> Since writing up my initial feedback I've run into this and similar
> problems to what Craig's had and when using the manage.py db
> functions. I don't have write access to some of my legacy db's and
> when it tries to create tables on syncdb or you're doing things like
> resetdb it can fail. Ultimately, I've just accepted it as fact and
> just generate the sql and run the sql by hand in the appropriate db's
> but I don't think that's going to make for a very long term solution
> (and at the very least it'll be something that you get slammed for in
> the users group ;)
>
> I definitely agree on the re-use front as well. It'll make
> distributing apps harder.
>
> JL.
>
> On Sep 3, 8:08 pm, Russell Keith-Magee wrote:
>> On Fri, Sep 4, 2009 at 8:56 AM, Craig Kimerer wrote:
>>
>> > On Thu, Sep 3, 2009 at 5:00 PM, Russell Keith-Magee
>> >
>> > wrote:
>>
>> >> On Fri, Sep 4, 2009 at 7:14 AM, Craig Kimerer
>> >> wrote:
>> >> > I've spent a little time using this branch and looking at the
>> >> > possibility of
>> >> > using it with my project. Below is a short list of problems and ponies
>> >> > that
>> >> > I have encountered (or want).
>>
>> >> > 1. It'd be awesome if we could mark certain databases as slaves.
>> >> > Inserts /
>> >> > deletes / creates / drops would only run on the masters (table creation
>> >> > and
>> >> > deletion specifically). I can skip the slaves by passing in the
>> >> > databases I
>> >> > want to sync, but I still have the next issue.
>>
>> >> So far, the implemented API is pretty low-level - it lets you direct
>> >> queries to a particular database, but the practical end-user API for
>> >> use cases such as slave/master hasn't been worked on that much. If you
>> >> go back to the original specifications, the suggested solution is to
>> >> put this in the manager, and so far I can't see any reason why this
>> >> won't work.
>>
>> > But if you list them in settings.DATABASES you have the problem below where
>> > tables try to get created on the slaves, which leads to errors because
>> > tables cannot be created on the slave. That was my main reason for asking
>> > if there was a way to skip them (I should have been more clear).
>>
>> At the moment it is true that all tables are created on all databases,
>> but that won't be true in the final version. This ties in with my
>> comment on your original point 2 - we need much better ways to
>> describe what data is on what database. Create/Write/Read access to
>> that data is part of that specification.
>>
>>
>>
>>
>>
>> >> > 3. I have multiple databases defined (some multiple times). It would be
>> >> > cool if we could 'ignore' certain databases. An example, I have 3 MySQL
>> >> > instances running. MASTER_MAIN_DB, MASTER_OTHER_DB, SLAVE_MAIN_DB. I
>> >> > want
>> >> > to be able to refer to them all, but also all the contrib apps I am
>> >> > using I
>> >> > want to live on MASTER_MAIN_DB. So in my settings I have:
>> >> > DATABASES = {'default': MAINDB_MASTER,
>> >> > 'MASTER_MAIN_DB': MAINDB_MASTER,
>> >> > 'SLAVE_MAIN_DB': MAINDB_SLAVE,
>> >> > 'MASTER_OTHER_DB': OTHERDB_SLAVE
>> >> > }
>> >> > Which means that when I run tests, it tries to drop tables on
>> >> > MAINDB_MASTER
>> >> > twice. Perhaps someone (Alex?) knows of a better way to do this?
>>
>> >> Is there any reason (other than clarity) that you want to be able to
>> >> explicitly refer to 'default' and 'MASTER_MAIN_DB'? Is there some
>> >> reason that it isn't practical to just call 'default' the main-master
>> >> database and refer to it as such?
>>
>> >> The reason I'm asking is that the duplication you are doing here will
>> >> result in you opening two different connections to MAINDB_MASTER. I
>> >> can't think of an obvious reason that this would e required. I suspect
>> >> we could work around the problem if we had some sort of aliasing in
>> >> the DATABASES definition (i.e., set up 'default' as an alias of
>> >> 'MASTER_MAIN_DB'), but before we add this, I'd like to understand the
>> >> use case to see if it is worth the effort (and potential confusion).
>>
>> > I could do that, it was mainly for clarity. Everything inside of my app
>> > would specify a using of that database. No other good reason, I can move
>> > it
>> > over to 'default' and 'default_slave' :).
>>
>> I'm yet to be convinced that `Meta: using` is actually a good thing.
>> IMHO, it's the very model of a setting that makes it impossible to
>> re-use your application
Re: Final Multi-DB status Update
On Mon, Sep 14, 2009 at 1:54 PM, Joseph Kocherhans wrote: > > > On Mon, Sep 14, 2009 at 12:16 PM, Alex Gaynor wrote: >> >> FWIW, Russ, Joseph Kocherhans, and I discussed this at the DjangoCon >> sprints and our conclusion was to have syncdb only sync a single table >> at a time, and to take a --exclude flag (or was it --include?) to >> specify what models should be syncd. > > Did you mean to say "sync a single db" instead of "sync a single table"? > Russ was talking about an --exclude flag at the sprints, but it doesn't > really matter either way to me. > Joseph > > > Yes :) 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-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: Replacing get_absolute_url, I am against it
On Mon, Sep 14, 2009 at 6:58 PM, Patrick J McNerthney
wrote:
>
> We are not (at least not now), endless discussing the color to paint the
> bike shed, we are discussing the fact that the bike shed is being built
> in entirely the wrong location. IMO, the proper place to build this
> particular bike shed is in the urlresolvers section of the city, not in
> the models section.
>
> Just like urlresolvers right now has a "reverse" method that can take in
> a view name, a similar method should be exposed that takes in a object.
> Something like:
>
> urlresolvers.reverse_for_object(object)
>
> In addition, most, if not all, of the current optional reverse arguments
> probably should be supported.
>
> Obviously, there are a few details to work out with regards to how to
> nicely configure the url resolvers sub-system to support this, but I
> believe that is where the bike shed belongs.
>
If the objective is to seperate the two systems why is having the URL
system know about Models more acceptable than having the Model system
know about URLs? This is most certainly a bike shed IMO.
Alex
> Pat McNerthney
> ClearPoint Metrics, Inc.
>
> Yuri Baburov wrote:
>> This is kind of incorrect question by itself.
>> It's MVC pattern you're trying to overcome with this sort of question.
>>
>> Model is not living anywhere on site!
>> Admin app instance ("View" and "Controller") is one that allows you to
>> manage specific model instances ("Model") and make guesses what's the
>> meaning of these models.
>> Admin app should have that get_object_url for the link "View on site"
>> if it needs to show that.
>> (Usually, it can use reverse for that).
>> You can subclass ModelAdmin to override get_object_url behaviour.
>> You can't override models easily without monkeypatching (subclassing
>> makes new model or you deal with model proxies only to override
>> get_object_url), that's why ABSOLUTE_URL_OVERRIDES hook was born.
>>
>>
>
>
> >
>
--
"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-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: Strange behaviour with exclude / filter and a nullable FK
On Tue, Sep 15, 2009 at 1:58 PM, Marcob wrote:
>
> On 15 Set, 19:32, Marcob wrote:
>
>> LEFT OUTER JOIN "auth_user" ON ("ticket_ticket"."assigned_id" =
>
> I translated from italian, obviously assigned_id should be
> assigned_to_id.
>
> Sorry.
>
> Ciao.
> Marco.
>
> >
>
This has already been filed as a bug in Django's ticket tracker:
http://code.djangoproject.com/ticket/10790. In the future please try
searching the tracker before filing a bug.
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-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: An issue with ticket system
On Fri, Sep 18, 2009 at 6:44 PM, Joshua Russo wrote: > I just tried to update a patch on a ticket that I had created but the file I > uploaded isn't displaying. It shows in the list and with the correct file > size but when I try to view the file it's empty. I've upload quite a few > patches previously so I'm pretty sure it's not my process. > http://code.djangoproject.com/ticket/11695 > here is the diff that I'm trying to upload > http://dpaste.com/hold/95397/ > Any suggestions? > > > If you press the original format button you will see that the patch is still there, trac just can't display all diffs (it's a very special piece of software). 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-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: Session/cookie based messages (#4604)
On Sun, Sep 20, 2009 at 11:30 PM, Chris Beaven wrote: > > > > On Sep 21, 12:05 pm, Russell Keith-Magee > wrote: >> On Mon, Sep 21, 2009 at 6:13 AM, Chris Beaven wrote: >> >> >> One of the questions that needs to be answered >> >> is "why should [a session based notification system] be shipped with >> >> Django?" >> >> >> Another piece of the puzzle that is missing from my perspective is any >> >> discussion of how session-based messaging interacts with the existing >> >> contrib.auth messaging framework. IMHO, Django shouldn't ship with two >> >> messaging APIs, so what is the integration point? >> >> > Having some kind of defacto cross-request notification system makes >> > sense; it's a very common usage pattern. >> > Attaching these kind of messages to a User instance is wrong: there is >> > not an enforced one to one correlation between a user and a session >> > [1], and you can't notify anonymous sessions. >> >> > The current contrib.auth messaging framework can't be removed or >> > replaced while keeping full backwards compatibility. A basic user >> > based messaging system still has it's uses, but it is not the best fit >> > for session notifications. >> > Side note: a pet peeve of mine is that contrib.auth messages are not >> > lazily loaded, which means you get a db hit every request [when using >> > a RequestContext] and lose your messages whether you use the messages >> > context var or not, but this is a side issue and should probably be a >> > ticket of it's own. >> >> > For some background, I initially started 4604 much more tightly >> > coupled with core, and one which backwards-compatibly worked with the >> > current user-based messaging system. Malcolm specifically requested >> > that this should be written as a stand-alone contrib app rather than >> > part of core, and that it should have minimal impact on existing code. >> >> Sorry - perhaps I need to be more clear on my intent here. I'm >> convinced of the importance of session-based messages - just not of >> when and how a particular implementation should be added to trunk. > > Thanks for your clarifications. > >> What I'm talking about is an orthogonal set of modifications that >> would allow for _any_ messaging system (database backed, session >> backed, or magic pony backed) to be used. This doesn't couple a >> particular implementation of session-based messages to the core, but >> it would allow for end-users to choose a session-based message >> framework if they found one that was appropriate to their needs. In >> the fullness of time, we may end up adding django-notify or similar to >> contrib, but if we add the plugable backend we can defer that decision >> until much later when implementations have stabilized and a clear >> implementation winner has emerged. > > django-notify is built on a pluggable backend architecture. > It comes with packaged with three backends, and custom backends are > also supported. > >> As it stands, I'm aware of at _least_ two >> implementations (django-notify and djangoflash), > > I agree, the decision is important to get right. > > To clarify, django flash is actually more than just a session > notification backend, it introduces a whole new temporary (but cross- > request) variable scope. > Leah has a messaging implementation which uses django-flash: > http://github.com/leah/django-flash-status > > So the question changes into, "are we after just a notification system > or do we want to have a more open (but arbitrary) system of a > temporary cross-request variable scope?" Forgive me, but isn't a "temporary cross-request variable scope" just sessions or cookies? 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-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: opener.dismissAddAnotherPopup error tinymce
On Tue, Sep 22, 2009 at 10:57 AM, Ali Rıza Keleş wrote:
>
> Hi all,
>
> There is something strange with popups on admin page while this page
> includes tinymce editor.
>
> When i click to add a relating object, a popup is being opened and i
> enter values and try to save. It is saved but popup is not closed and
> give this error on firefox:
>
> """
> opener.dismissAddAnotherPopup(window,"2",
> "some_value");
>
> Permission denied to get property Window.dismissAddAnotherPopup
> http://local.arha.com.tr/admin/content/author/add/?_popup=1
> Line 1
>
>
>
> and this error on opera:
>
> """
> opener.dismissAddAnotherPopup(window,"2", "some_value");
>
> Inline script thread
> Error:
> name: ReferenceError
> message: Security error: attempted to read protected variable
> 'dismissAddAnotherPopup'
> stacktrace: n/a; see opera:config#UserPrefs|Exceptions Have Stacktrace
>
>
>
> If same page has no tinymce, everything works very well.
>
> My tinymce initializer has
>
> """
> document.domain = 'arha.com.tr'
> tinyMCE.init({
> mode: "textareas",
>
>
>
> """
>
> because media files are being served via another server named as a
> subdomain.
>
> Thanks..
>
> --
> Ali Rıza Keleş,
>
>
>
> >
>
Please don't cross post to django-dev and django-users, in this case
django-users is the appropriate place for your question.
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-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: decorator_from_middleware change
On Tue, Sep 22, 2009 at 6:04 PM, Jacob Kaplan-Moss wrote: > > On Tue, Sep 22, 2009 at 4:16 PM, Luke Plant wrote: >> James B - do we have a place to list things like this i.e. things >> that probably should go in release notes? > > I think it'd probably be best to just start > docs/releases/1.2-alpha.txt right now. We can list this stuff as we > add it, and then someone (probably James or I) can clean it up into a > solid doc in time for the release. > > Jacob > > > > Note that we now also have the: http://docs.djangoproject.com/en/dev/internals/deprecation/#internals-deprecation page for documenting depercated items. 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-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: Auth/Session modules and JSON views
On Wed, Sep 23, 2009 at 8:58 PM, django_fo...@codechimp.net wrote: > > This is probably a dumb question, but I am working on some JSON views > that I need to apply authentication too. I thought maybe I could use > the Django built-in auth/session apps to wrapper the JSON View > methods, but when I do testing I am not seeing the session id being > sent back. I tried hitting the service from FireFox and from the > iPhone app I am working on, and neither seem to get any headers back > from the server containing anything resembling a session id or cookie > header of any sort. > > General rule of thumb: What is the recommended way to secure a JSON > view and where might one find documentation on how this should look? > > Again, I do apologize if this is a dumb question and/or there is > documentation somewhere. I swear I did google and read through the > docs I saw here online and I didn't see any mention of JSON security. > > > > The django-developers mailng list is for the discussion of the development of django itself. Please ask this question on the django-users mailng list. 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-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: Django IIS
On Wed, Sep 23, 2009 at 9:18 PM, Ronn Ross wrote: > Can Django run on IIS? > > > > The django-developers mailng list is for the discussion of the developmeny of django itself, not developmeny with Django. Please ask the django-users maing list. 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-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: CSRF - next step?
On Sat, Sep 26, 2009 at 2:29 PM, Luke Plant wrote: > > Hi all, > > I just want to know what the status is before committing the CSRF > stuff: > > * Jacob am I waiting for a thumbs up? I think you said you were going > to try out the code. > * Simon am I waiting for your patch? > > If I'm not waiting for either, my plan would be: > * Commit what I've got pretty much as is. > * Then move it all from contrib to core > * Question: where should the docs (currently ref/contrib/csrf.txt) > be moved to? ref/csrf.txt seems like a sensible place, but I > don't know. > * Then add a render_to_response_with_request shortcut (once we > can decide on a colour...) and adjust the tutorials. > So I'm still a little unclear on what this shortcut does that direct_to_template doesn't already? > Simon: > * I could wait for you to write your csrf_protect_form code before > doing any of this, merge it and then do the above. > * You could write it against my lp-csrf_rework branch (which is not > going to change substantially), and I can move your patch > over to core (or you could move it). > * You could wait 'til I'm done so that we don't have to worry about > the fact that everything is going to move. > > Personally, I think your patch would be better going in separately, as > it is additional functionality that is not used by default anywhere. > > Also, I have written a Python script that attempts to help people find > all the s and view code that needs attention. It has a whole > bunch of limitations and caveats, but I think it's pretty useful 90% > solution and automates a lot of what people would have done using grep > etc. Where should it go? It's currently in 'extras/' which seems to > be the right place. > > Luke > > -- > "Smoking cures weight problems...eventually..." (Steven Wright) > > Luke Plant || http://lukeplant.me.uk/ > > > > 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-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: Model.objects.raw() (#11863)
On Mon, Sep 28, 2009 at 9:24 PM, SeanOC wrote: > > Hello All, > > During the Djangocon sprints I started to work on a patch which would > add a nicer interface for dealing with raw SQL queries. While there I > talked to RKM about where it should fit into the ORM API and where in > the code base should live. I've finally gotten around to finishing > the code I wrote during the sprint and have posted a patch to the > related ticket (http://code.djangoproject.com/ticket/11863). You can > also get the code from http://github.com/SeanOC/django. > > So far the patch is functional and has some basic unit tests but it is > not documented. I'll be working on the documentation this week. In > the mean time, the unit tests are probably the best place too look for > how to use the code. > > If anybody would like to look over the code and provide some feedback > it would be greatly appreciated. > > Thanks! > > -SeanOC > > > So my question, and this is something I've been thinking about a lot of the proposals lately is: why should this be in Django itself. This looks to me like something that would work perfectly well outside of Django itself, indeed it's just a custom manager. 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-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: Final Multi-DB status Update
On Tue, Sep 29, 2009 at 11:48 AM, Rob Madole wrote: > > Hmm. I just spent some time looking at #11828, and I don't think the > "syncing one db at a time" will work. The first problem this causes > is with anything that subscribes to the post sync signal. Content > type does this, so it can create permissions. If we sync one db at a > time, I don't see how content type can do it's job. > > My response in the ticket was to just make sure that default get's > sync'd first, guaranteed. But based on what JL said about resetdb and > running the SQL manually it sounds like the roots go down a little > deeper. I disagree with myself now. > > What if syncdb did this in two phases. It goes through every db > connection and creates the appropriate tables. Then do everything > else. > > Oh and I certainly think that tables should only exist for the db's > they apply to. I had a yuck moment the first time I opened up the db > and saw those empty tables. This one is going to be a hard sale on > our dev team. I'm anticipating the argument I'm going to have with > the DBA'ish fella on the team. > > Rob > > On Sep 14, 2:57 pm, Alex Gaynor wrote: >> On Mon, Sep 14, 2009 at 1:54 PM, Joseph Kocherhans >> >> >> >> >> >> wrote: >> >> > On Mon, Sep 14, 2009 at 12:16 PM, Alex Gaynor >> > wrote: >> >> >> FWIW, Russ, Joseph Kocherhans, and I discussed this at the DjangoCon >> >> sprints and our conclusion was to have syncdb only sync a single table >> >> at a time, and to take a --exclude flag (or was it --include?) to >> >> specify what models should be syncd. >> >> > Did you mean to say "sync a single db" instead of "sync a single table"? >> > Russ was talking about an --exclude flag at the sprints, but it doesn't >> > really matter either way to me. >> > Joseph >> >> Yes :) >> >> 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 > > > > It's worth noting that even if our end solution is to sync all DBs to all tables you would be able to DROP the tables and not worry about them. Not saying we should go with that solution (in fact I really think we shouldn't), but the extraneous table creation isn't a huge deal in my view. 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-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: Adding an option to re-test only failed tests
On Tue, Sep 29, 2009 at 1:58 PM, Simon Willison wrote: > > On Sep 29, 5:03 pm, Rob Madole wrote: >> I've been using nose for our tests, and one of the features that I >> really like is the ability to run the tests again but filter only the >> ones that caused a problem. >> >> I'm thinking it would look something like this >> >> ./manage.py test --failed >> >> Does this sound worthwhile to anybody? > > I don't understand how this works - does it persist some indication of > which tests failed somewhere? If so, where? > > If we're talking about features from nose, the two I'd really like in > Django's test runner are --pdb and --pdb-failures: > > --pdb = when an error occurs, drop straight in to the interactive > debugger > --pdb-failures = when a test assertion fails, drop in to the debugger > > Cheers, > > Simon > > > If we're throwing off testing ponies: --failfast. Runs the full test suite as normal but as soon as it hits a failure it spits out the fail and ends. Unladen Swallow added this to their test suite and it's a huge help in terms of not running the full test suite to see what the failure was. 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-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: ORM roadmap
On Sat, Oct 3, 2009 at 2:58 PM, Thierry wrote: > > http://code.djangoproject.com/wiki/Version1.2Features > > I know this is not a problem for most users. But when working with > complex projects or projects requiring some performance optimization > django orm doesn't suffice. Its a pity to see strong development on > django orm, while at the same time the sqlalchemy project has huge > traction. I currently run both orm's. The gap between sqlalchemy and > django orm is very large. Are there any plans to integrate sql > alchemy? > > > > No. There are no such plans, we wouldn't be doing development of our own ORM if we planned to throw it away. There have been external projects to integrate SQL Alchemy into Django, but I hvae no idea what the status of them is. 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-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: Proposal for 1.2: built-in logging with django.core.log
On Fri, Oct 9, 2009 at 6:12 AM, Luke Plant wrote: > > On Friday 09 October 2009 10:33:28 Simon Willison wrote: >> For anyone interested in following this, I've just started a >> (currently experimental) branch on GitHub: >> >> http://github.com/simonw/django/tree/logging > > Is there some easy way to see the patch? Preferably a link which will > just show the diff between the latest of your branch and trunk, but > failing that, a recipe of commands using git (for those of us who > haven't bothered to learn git properly yet). > > Cheers, > > Luke > > -- > "We may not return the affection of those who like us, but we > always respect their good judgement." -- Libbie Fudim > > Luke Plant || http://lukeplant.me.uk/ > > > > Don't we wish it was possible for github to show a diff between two branches... :( Just venting'ly yours, 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-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: Proposal for 1.2: built-in logging with django.core.log
On Sat, Oct 10, 2009 at 9:11 AM, Vinay Sajip wrote: > > > > On Oct 10, 1:56 pm, Simon Willison wrote: >> I just hacked in a logger that increments a counter for every message >> - it indicates that there are 158,527 SQL statements executed by the >> test suite, which means we should expect to add slightly over a second >> to the time taken for the overall unit tests based on the >> microbenchmark. > > You don't need to hack a logger to do this - you can just add a Filter > which passes everything but counts as it goes. > > Anyway, the numbers don't look too bad at the moment :-) > > Regards, > > Vinay Sajip > > > It's worth noting that though we should be considered with extreme effects were they to occur, over in Mountain View we have some friends working to make this not an issue for us :) . If Django is run under Unladen Swallow the result of all of these calls will be that both the logger function itself, and the code that calls it (for example the execute SQL query function) will be considered HOT by the interpreter and compiled down to machine code. There at that stage the compiler will be able to apply some nice heuristics and since this function never gets monkey patched or changed the compiler will be able to inline it. Since almost all log handlers will be trivial, the inlining will effectively give us 0-overhead logging. Compilers are awesome'ly yours, 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-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: Proposal: Tutorial Refresh
On Sun, Oct 11, 2009 at 7:24 AM, andybak wrote: > > Another thing that might be useful to cover in the tutorial is the > 'building for re-usability' ideas that have devloped via Pinax et al. > > Maybe at least one part of the functionality developed in the tutorial > should be in the form an app intended to be used across projects. > Combine this with incorporating existing 3rd party apps in the project > and we've captured a very powerful lesson about Django. > > (edit - this is already hinted at in some of the other comments but > I'll still post this for the extra emphasis) > > > I don't want to be overly negative, but in my view rewriting the tutorial would be a pointless waste of energy. It has served us exceptionally well over the past 4 years, and none of the problems with it are fundamental, we'd be far better served by working to improve it, by adding more stages, than by rewriting it. Further, I'd ague that the "staleness" of the tutorial is irrelevant, because the primary audience for the tutorial are precisely people who haven't seen it before. 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-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: #7539 Add ON DELETE and ON UPDATE support
On Tue, Oct 13, 2009 at 4:36 PM, Michael Glassford wrote: > > > > Jani Tiainen wrote: >> Michael Glassford kirjoitti: >>> >>> Jani Tiainen wrote: Is there anyone working for this ticket? There seemed to be few patches but then a silence. I would be interested in to help/implement that feature since it's very highly needed feature in our own code. >>> I am. The silence is due to a couple of problems I've been looking into, >>> but I'm thinking of posting a patch with the problems and getting >>> suggestions on how to deal with them. Maybe later today. >> >> Glad to hear and I'm pretty happy to help to test things (specially on >> Oracle DB). >> > > I've added a new patch and comment to > http://code.djangoproject.com/ticket/7539. > > > > > Can you upload it with a .diff extension so we can get proper code highlighting on trac. 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-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: lazy auth context processor
On Wed, Oct 14, 2009 at 8:24 AM, Luke Plant wrote:
>
> I want to fix #6552 (also #12031), and I've attached a patch that
> makes the auth context processor lazy.
>
> I'm pretty sure this is the right thing to do, but I'd like to check
> for any gotchas people might be aware of.
>
> Some behavioural changes:
>
> * user.get_and_delete_messages() will not be run if the page template
> doesn't iterate over 'messages'. If you had a view which set some
> messages, followed by a template (that used RequestContext) which
> didn't display messages, it would silently delete messages. Now,
> those messages will be displayed at a later point. I think this is a
> bug fix, not a problem.
>
> * the output of {{ user }} in a template will be different. I think
> this is acceptable, because only things like {{ user.username }} are
> actually useful, apart from when debugging.
>
> Other eyeballs on the patch would be welcome.
>
> Luke
>
> --
> "You'll be glad to know, I'm going to donate all the snot I sneeze
> to hospitals for mucus transfusions." (Calvin and Hobbes)
>
> Luke Plant || http://lukeplant.me.uk/
>
> >
>
I think changing the result of {{ user }} in the template is a bad
idea. Luckily it can easily be solved by adding an __unicode__ method
that proxies the request to the wrapped object.
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-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: shortcut proposal
On Fri, Oct 16, 2009 at 12:05 PM, Michael P. Jung wrote:
>
> Some time ago I came up with a decorator to enable rendering jinja2
> templates easily. The decorator 'monkey patches' the request object by
> providing a __getattr__ method and adding some new methods.
>
> https://labs.pyrox.eu/common/jinja2/tree/django.py
>
> This could be easily adapted for django templates, though I'm not a huge
> fan of this solution anymore.
>
>
> I've found it to be way more practical to just store the request object
> inside a threading.local object and let my functions access it directly.
>
> That would allow you to write very simple view functions that don't even
> need the request to be passed as argument.
>
> from django.http import request
>
> def index():
> return response('index.html', user=request.user)
>
>
> A nice side effect of this would be that the whole middleware thing for
> adding lazy fields to the request object becomes obsolete, too. No more
> passing around request objects like a madman in order to access the
> request object inside template tags, filters, ModelAdmins, etc.
>
>
> Getting rid of the superfluous request argument would be more a pony
> request for Django 2.0, as it'd break a lot of code. I like the idea
> nonetheless.
>
>
> --mp
>
> >
>
Quite simply, no. Storing anything in a threadlocal instead of
passing it around is indicative of bad coding practice, and poor
architecture.
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-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: Django SAAS
On Fri, Oct 16, 2009 at 8:00 PM, Savy wrote: > > > > I am developing a Django project (with a few pluggable apps). > > I want to offer this project as a SaaS (something like 37signals.com). > > i.e: customer1.product1.com , customer2.product2.com etc > > product1 could be the basecamp product2 could be highrise and so on. > > I want to know how the project should be structured for these > products. > > Should there be a single project under which all products will be an > application. OR Should I be making different projects for > all the products. > > Also interms of database.. should all the products look into a single > database or we should have seperate databases for each product. > > I am looking out for the most efficient and scalable way to do this. > > Thanks > > > django-developers is for the discussion of the development of django itself, not development WITH django. You should use the django-usres mailing list for this. 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-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: Custom fields and PostGreSQL composite types
On Tue, Oct 20, 2009 at 2:50 PM, thierry wrote: > > Hello everybody, > > I'm working on a scientific project and Django has been chosen to > develop our database model. I'd like to develop a > 'PhysicalQuantityField' that manages a value and its relative unit. > > The first way to do this stuff is to translate the couple (value,unit) > into a string and use Django custom field to manage the translation > between Python and PostgreSQL. It works perfectly but I don't like the > fact to mix the value and the unit. Moreover, postgres stores a string > rather than a numeric and It makes me feel that the database model is > not really clean. > > The second way, and in my mind the cleaner way, is to create a > composite type at the postgres side called 'physicalquantity' with > "CREATE TYPE physicalquantity AS (value numeric,unit varchar)". It is > possible to add data to the database, but not to search data because > the where clause of a select query, generated by a get or filter would > be : > > (with measure as a composite type) > > SELECT measure > FROM myapp_mytable > WHERE measure = '(10,"mV")' > > That is incorrect. The correct query would be : > > SELECT measure > FROM myapp_mytable > WHERE (measure).value = 10 > AND (measure).unit = 'mV' > > Can you tell me if there is a way to control the content of the where > clause from the custom field class ? > > If not, do you think Django will be able one day to manage composite > types ? > > Cordially, > > Thierry. > > > > I think your best bet would be to make 2 fields, a numeric field (integer, decimal, float whatever you need) and a charfield or something with the units and then just have a property in Python that returns what you want. Basically implement this the same way as GenericForeignKeys. As for whether Django will eventually support Composite data types, I think the answer is maybe, AFAIK no one has worked on this (besides composite primary keys which may be related implementation wise). So the first step would be for someone to come up with a design/API for what it should look like. 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-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: 1.2 Feature Suggestion
On Fri, Oct 23, 2009 at 10:21 AM, Jonas Obrist wrote: > > How about making i18n strings translatable from the django admin site? > I like how the whole i18n thingy is built from a template perspective, > however getting the stuff actually translated (all those django-admin.py > commands ...) is a pain and confusing. So why not integrate this into > the amazing admin site and make it even better? > > > > A few things: a) The feature proposal phase has already passed, it went on for the last 3 months or so. b) There's already an external application that does this: http://code.google.com/p/django-rosetta/ 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-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: 1.2 Feature Suggestion
On Sat, Oct 24, 2009 at 6:50 PM, veena wrote: > > Does the commentators have experience with maintaining the i18n django > project? I do and completely agree with Jonas. > "Gettext like+Rosetta like" but database driven translation app in > Django adminwithout translation-makemessages-compilemessages-restart > apache would be helpful. Import from the gettext file (managed by your > standard tool) to db could be also provided. > > Vaclav > > > > On Oct 23, 6:13 pm, Simon Willison wrote: >> On Oct 23, 3:30 pm, Jonas Obrist wrote: >> >> > Oh... Well than consider this a 1.X suggestion. I've tried Rosetta >> > however it just doesn't seem to work Also I don't really like to use >> > 3rd Party apps for what I'd consider core functionality. I mean django >> > boasts with having excellent i18n capabilities, but when it comes to >> > actually translating stuff it just refers to a 3rd party app >> >> My understanding is that translation tools are actually quite a >> controversial issue within the translation community. Most translators >> work on more than just one piece of software - they might help out >> translating Django, Firefox, Emacs and a bunch of other stuff. As >> such, they generally have their own standard tool that they work >> within for managing all of their translation activity. A Django- >> specific tool wouldn't actually help them at all, since they wouldn't >> be able to use it for the other translation work that they do. >> >> As such, I don't think a single translation management tool should >> ever be shipped as part of Django. It's too sticky a problem, and >> hence is definitely best addressed by third party modules such as >> Rosetta. > > > I can't comment on the other people's work with i18n, but I've been doing updates the Hebrew translations for the past couple of releases. I'm not sure what perspective people have, but as a developer doing translations, needing to load up the CLI to make/compile messages doesn't bother me, I'm going to need my CLI for doing the final diff anyway. IMO if you need a full web translation system you should be looking at something like Transifex[0], which is clearly out of scope for Django itself. Alex 0: http://www.transifex.net/ -- "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-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: __in and comma-separated strings.
On Tue, Oct 27, 2009 at 11:57 AM, Jerome Leclanche wrote: > > I've got a patch to let __in accept comma-separated strings; I'm using > this locally to avoid going through the trouble of splitting a string > before processing a GET. The exact same technique is used in > django-admin, and I'd bet many other apps as well. > > Is there a reason why this behaviour isn't default, or should I send > the patch? __in will break on strings as far as I'm concerned. > > > J. Leclanche / Adys > > > > I'd be -1 on this, this ties __in to an arbitrary serialization format for no good reason. Your view you knows what your particular logic is, Django's ORM shouldn't be making wild guesses. Ale -- "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-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: __in and comma-separated strings.
On Tue, Oct 27, 2009 at 12:19 PM, Jerome Leclanche wrote: > > It's not... if you got control over the code. However my patch is > specifically targeted at GET processing. You have to add a bunch of > checks after each other, it quickly becomes overwhelming. > > Alex, I'm interested by what you mean exactly by "tying __in to an > arbitrary serialization format". What else would you propose? > > > J. Leclanche / Adys > > > > On Tue, Oct 27, 2009 at 6:08 PM, Jacob Kaplan-Moss wrote: >> >> On Tue, Oct 27, 2009 at 10:57 AM, Jerome Leclanche wrote: >>> I've got a patch to let __in accept comma-separated strings; I'm using >>> this locally to avoid going through the trouble of splitting a string >>> before processing a GET. >> >> I'm -1 on this. Is `filter(foo__in=s.split())` really all that hard? >> >> Jacob >> >> > >> > > > > I meant precisely what I said, comma separating values in a GET string is a fairly arbitrary means of serializing a value, in past I've seen other characters used (or just having multiple values in the querystring such as a=3&a=4), assuming a comma separated value is the definition of arbitrary. As for what I would propose instead: nothing, what we have now works. 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-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: non-relational DB
On Thu, Oct 29, 2009 at 2:44 PM, Waldemar Kornewald wrote: > > Hi, > Russell and Alex, did you already look at QueryGlue? We really need to > discuss which branch the new query_class() should be in. > > Bye, > Waldemar Kornewald > > > > I haven't had a chance to look at it, and I probably won't until at least a few of the items on my plate are dealt with. That being said I am extremely leery about investing time in something with names like "QueryGlue" as to me they imply a lack of organization in the code, and that may of may not be true, but giving things name thats are at least somewhat explanatory to outside users really helps. 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-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: Advocacy for Email-01 (email backends)
On Fri, Oct 30, 2009 at 10:58 AM, Luke Plant wrote: > > On Sunday 25 October 2009 07:22:27 Russell Keith-Magee wrote: > >> I'm keen to see a resolution to this problem. To that end, I'm >> interested in hearing specific criticisms or concerns with the >> current backend proposal. I'm also interested in any alternate >> approaches to this problem. > > I'm completely fine on this proposal. Apparently I voted '-0', I'm > not sure precisely why as I didn't leave any specific comment, but I > would change that to +0 now (I have no specific need for it myself, > but can see that it's an important improvement for lots of people, and > it can be implemented cleanly). > > I presume that the only built-in email backends would be the existing > SMTP one, one for testing (which is just a code shuffle really), and a > 'write to standard out' one for debugging (which is trivial and > completely un-critical anyway), so this doesn't really add any > maintenance burden to Django. > > Regards, > > Luke > > -- > A common mistake that people make when trying to design something > completely foolproof is to underestimate the ingenuity of complete > fools. -- Douglas Adams > > Luke Plant || http://lukeplant.me.uk/ > > > > Amusingly it appears that since Jannis got his wings^H^H^H^H^H^H commit bit his -1 became a veto :) 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-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: Regularly-scheduled Django sprints, first December 11 - 13
On Tue, Nov 10, 2009 at 11:00 AM, Jeremy Dunck wrote: > > Djangonauts, > To help speed along development on Django, I'd like us to start > holding regularly-scheduled sprints. I've previously contacted core > committers to see who would be willing to supply the commit bits for > the sprint workflow. I'm now looking for members of the dev list to > help organize locally. If you would be willing to help organize your > local Django developers, the DSF can pay for lunches or similar costs. > It doesn't take much effort-- you just need a place to work that > offers a good network connection and a little coordination to get > people together. If you're an experienced contributor, great, but > there will be people on #django-dev and #django-sprint to help out, > too. We can certainly get a committer available online. In some > cases, we can get a committer on-site to help things along as well. > > To start, let's try running a sprint once every two months. I don't > think the specific days matter too much, but for a start, let's say > the second Friday through Sunday of every second month, starting in > December. That would make the first scheduled sprint December 11 - > 13. Since we have developers world-wide, I think it would make sense > to have the sprint roll across the time zones, starting at Fri 11 Dec > at 18:00 UTC [1] and running continuously until Mon 14 Dec at 00:00 > UTC [2]. Within that range of time, local groups can gather with some > assurance that a committer will be available at least virtually. > > It'd be lovely to get more than one location per sprint, and I'd > like to ensure that people all over at least have a reasonable chance > to attend a gathering. The exact days and start times will be up to > local organizers-- I'm just trying to make some conventions so we > don't have to fiddle with configuration so much. > > If you're willing to organize a sprint gathering during this time > span, please let me know and I'll help to ensure committers are > available and to promote the sprint gathering. (There's actually > pretty good guidance on the Sprints wiki page [3].) > > Even if you can't host on those dates, but would like to host in the > future, please let me know so I can have a list of candidates to work > from in the future. > > [1] > http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=12&day=11&hour=18&min=0&sec=0&p1=64&p2=37&p3=196 > [2] > http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=12&day=14&hour=0&min=0&sec=0&p1=64&p2=37&p3=196 > [3] > http://code.djangoproject.com/wiki/Sprints > > > > >From December 19th through January 24th I will be willing to do anything necessary to organize a sprint in Chicago, hopefully it won't be too hard to drag our local core devs there :). Let me know what the sprint date would be over that time period and I can start working things out. 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-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: Regularly-scheduled Django sprints, first December 11 - 13
On Tue, Nov 10, 2009 at 11:14 AM, Sean Brant wrote: > > Alex, I can help you out in Chicago if you need it. > > Sean > > > > Sure that'd be great, I guess we don't really need to start planning until it gets a little closer, but if we want to have any discussions about the local things let's try to revive the django-chicago mailing list :) 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-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: Template filter for "in"
On Tue, Nov 10, 2009 at 3:54 PM, Tim wrote:
>
> I haven't seen any notes on the subject, so I pose the question:
>
> Would there be warm reception for a new built-in filter called "in",
> to provide the template system with the Pythonic keyword? A full-blow
> `{% if a in B %}` syntax would be great, but either one works. The
> template language so intentionally mimes Python keywords that it seems
> odd that "in" is left out.
>
> You can imagine the simplicity of a filter, but in the name of being
> quite specific as to what I'm suggesting:
>
> �...@register.filter(name="in")
> def _in(needle, haystack):
> return needle in haystack
>
> Pardon the PHP-ism of variable names.
>
> I realize this is simple enough for a little custom templatetag
> library to implement outside of the Django core, but it *does* fill in
> that hole in the template language that I mentioned. My little
> internal debates can't decide if the "in" functionality makes a better
> if-tag extension, or if it's better suited as a filter. (Or both.) A
> Filter is more appealing to me, because it can be used in several
> other constructs, most notably `{% firstof ... %}`, as a simple
> argument: "a|in:b".
>
> Thus:
> 1) Is this worth adding to the ticket system, with a patch, or
> should I content myself to my little custom library filter?
> 2) If it's worth the consideration, would a filter, a tag or both be
> most appropriate?
>
> Opinions obviously are welcome.
>
> Tim
> >
>
This is already covered by the Templates-02 item on the 1.2 features
list, the smart-if tag. This tag includes support for "in"
operations.
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-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: Template Caching - Ticket #6262
On Wed, Nov 11, 2009 at 8:15 PM, Mike Malone wrote: > Sup, > > I've been working on template caching (ticket #6262) with a mister > Alex Gaynor. The patch is getting pretty stable and I think it's close > to merge-able, so if anyone wants to take a look at what we've got and > provide feedback: go! > > Interesting background reading for people who haven't been part of > this conversation: > http://groups.google.com/group/django-developers/browse_thread/thread/b289b871285b86f5/b97ba9e2e9b9ad86 > > Ticket: http://code.djangoproject.com/ticket/6262 > > Latest patch: > http://code.djangoproject.com/attachment/ticket/6262/cache_templates.5.diff > > The more code reviewers the better, but if you don't have time to read > through the nitty gritty here's a high level overview of the changes: > > 1. The workhorse django.template.loader.get_template() function will > now return compiled Template objects directly if a template loader > returns one (where a Template object is defined as something with a > render() method). > 2. A RenderContext has been added to Context instances. This is > necessary so we can give template.Node instances a thread-safe place > to store state between calls to Node.render(). > 3. The built-in template tags were updated to use the render context > (specifically, CycleNode, BlockNode, and ExtendsNode). > 4. A caching loader has been added to the set of default loaders. To > use it, you instantiate the loader, passing a list of other loaders > that it should wrap. The first time you ask the loader for a template > it'll go through the wrapped loaders and find it, then cache it in > memory. Subsequent requests for the same template are served from > cache. Hazzah! > > The patch is pretty complete, it includes tests and docs, so please > take a look! I stuck the updated docs up on my website temporarily, so > if you want to take a look at them in a slightly more readable format > you can check out these URLs: > http://immike.net/django-docs/ref/templates/api.html#loader-types > http://immike.net/django-docs/howto/custom-template-tags.html#template-tag-thread-safety > http://immike.net/django-docs/ref/templates/api.html#using-an-alternative-template-language > > Thanks, > > Mike > > -- > > 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=. > > > As Mike said I've been reviewing this patch and I'm basically happy with it's current state. My one thought was whether to add a CACHE_TEMPLATE_LOADERS setting, and any loaders in that are cached by the CachedLoader (assuming it's instantiated with no arguments, it'll still be possible to explicitly instantiate it with loaders). 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=.
Re: Documentation of backwards incompatible changes
On Fri, Nov 13, 2009 at 11:15 PM, Russell Keith-Magee wrote: > On Sat, Nov 14, 2009 at 8:55 AM, Luke Plant wrote: >> Hi all, >> >> The online docs can easily give the impression that we have perfect >> compatibility with Django 1.0 — the 'Django over time' section on [1] >> has a link to 'Backwards-incompatible changes' [2], which contains >> pre-1.0 changes only, and a notice at the top saying you don't need to >> read it if your code is post 1.0. Also, the archive of release notes >> [3] incorrectly says that BackwardIncompatibleChanges is the place to >> look for those following trunk. It's a bit of a mess actually. > ... >> Thoughts? If other people think this is the right idea, links from >> the official docs to BackwardsIncompatibleChanges just need to be >> changed to UpgradingNotes. > > I agree that the current situation is a bit of a mess, and needs to be > cleaned up. > > My only question is the extent to which the wiki needs to be involved. > I'm not a huge fan of wikis, especially for official material. In > particular, I don't like the fact that we need to be constantly > vigilant and gardening the weeds when a spammer decides to post links > to his favourite porn/essay site. > > The details you currently have on the UpgradingNotes page are > essentially duplicates of what will eventually be in the 1.2 release > notes. So why not cut out the middle man and just use those release > notes? > > We can add a stub set of 1.2-final release notes right now, with a big > header that reads "1.2 currently in development". Whenever someone in > the core adds a new feature, we add a section to the 1.2 release docs. > If that means backwards incompatibilities, then make the appropriate > notes. > > The home page would then link to the release notes index page; this > page will need a bit of a cleanup to make the notes of past alpha/beta > releases less prominent, but that page could do with a cleanup anyway > (since it has a reference to the backwards incompatible wiki, too). > > This has the added benefit that writing the release notes becomes a > lot easier when the time comes - rather than scouring the history for > interesting features, Jacob and James just have task of editing. > > 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=. > > > I'm a big +1 on starting the release notes now. Most other projects I know of start them right after they branch for the release. This also saves James from pestering us in IRC on the night of releases asking what's new :) 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=.
Re: Template Caching - Ticket #6262
On Mon, Nov 16, 2009 at 8:58 AM, Russell Keith-Magee
wrote:
> On Thu, Nov 12, 2009 at 9:15 AM, Mike Malone wrote:
>> Sup,
>>
>> I've been working on template caching (ticket #6262) with a mister
>> Alex Gaynor. The patch is getting pretty stable and I think it's close
>> to merge-able, so if anyone wants to take a look at what we've got and
>> provide feedback: go!
>>
>> Interesting background reading for people who haven't been part of
>> this conversation:
>> http://groups.google.com/group/django-developers/browse_thread/thread/b289b871285b86f5/b97ba9e2e9b9ad86
>>
>> Ticket: http://code.djangoproject.com/ticket/6262
>>
>> Latest patch:
>> http://code.djangoproject.com/attachment/ticket/6262/cache_templates.5.diff
>
> Hi Mike,
>
> Here are my review comments. On the whole, I like what I see. These
> are pretty much all fairly minor bugs, documentation, or cosmetic
> interface changes.
>
> * In the process of reversing the direction of the stack in Context,
> the get() method has been neglected - it's still using the old stack
> direction.
>
> * The '.loader' extension on TEMPLATE_LOADER entries is consistent
> with the old TEMPLATE_LOADER settings (i.e., pointing at a specific
> instance/method), but not with the other pluggable backend APIs that
> we have.
>
> For example, when you specify the caching and mail backends, you
> provide the name of the module, and it is assumed that the backend
> module will contain a CacheClass and EmailBackend class, respectively.
> For the sake of consistency and clarity, I'd rather see the 'loader'
> name suffix as the implied (and required) name for the object in the
> loader module, rather than needing to explicitly specify the name of
> the loader instance.
>
> Obviously, the legacy support for the get_template_loader function
> will need to be an exception here, but moving forward, we should be
> aiming at a clean API.
>
> * On the subject of specifying loaders - in order to use the cached
> loader, we need to import the cached loader, and have support for
> callable loaders in find_template_loader. Requiring imports in the
> settings file seems like a bit of a wart to me.
>
> Here's an alternate proposal - rather than allowing callables, how
> about allowing entries in TEMPLATE_LADERS to be tuples, and
> interpreting the [1:] elements of the tuple as the arguments to the
> loader - for example:
>
> TEMPLATE_LOADERS = (
> ('django.template.loaders.cached', (
> 'django.template.loaders.filesystem.loader',
> 'django.template.loaders.app_directories.loader',
> )
> )
> )
>
I think this could get fairly complicated quickly, for example is this valid?
TEMPLATE_LOADERS = (
('django.templaet.loaders.cached', (
('django.template.loaders.filesystem', (
'/home/alex/django/templates/',
)
)
)
Frankly it seems more trouble then it's worth, adding a
CACHED_TEMPLATE_LOADER setting, though vaguely un-dry seems a good
deal cleaner.
> Theoretically, this means we could do away with the TEMPLATE_DIRS
> setting, since we could specify template directories in the same
> fashion. In practice, this probably isn't worth doing, but it is worth
> pointing out as a possibility.
>
> This also means we could get away from needing a module-level
> instantiation of Loader() objects - you just look in the module for
> the Loader class, and find_template_loader instantiates it with the
> appropriate arguments (or no arguments if the loader is specified as a
> string, rather than a tuple)
>
> * As someone who will need to maintain this documentation over time,
> I don't want to have to keep abreast of changes in other template
> languages to ensure that Django's documentation is accurate. I have no
> problems with mentioning Jinja and Cheetah as other languages that
> could be supported in theory, but I'd rather not give the specific
> implementation example.
>
> * Also on documentation - the load_template_source methods should be
> mentioned in internals/deprecation.txt, and the cached templates
> feature should noted in the 1.2 release notes.
>
> * The load_template_source methods should raise a PendingDeprecationWarning
>
> * Lastly - and this is really the only hairy one - the fate of
> django.template.loader.find_template_source().
>
> This method isn't documented publicly, but the backwards-compatibility
> notes provide that "everything documented in the linked documents
> below, and all methods that don’t begin with an underscore – will not
> b
Oracle/GIS Testers Needed
Hey all, Russ and I have been working on getting the multi-db work ready for merge (final stretch here hopefully!), and I just ported the Oracle backend to the slightly updated backend arcitecture so it could use some testers. If you've got an Oracle setup and can run some tests that would be great. You can grab the code here: http://github.com/alex/django/tree/multiple-db Make sure you use the multiple-db branch. I understand running the tests under Oracle can be a bit slow, so perhaps start by just running the "queries" tests, if they fail please reply with the complete tracebacks and such here, otherwise if you have the time a shot at running the full test suite would be great. For GIS I'm fairly certain that's broken, however I'm not quite setup for running the GIS tests yet, therefore if you're set up for it and can run the tests please just reply with your tracebacks here (preferably with them on a pastebin like paste.pocoo.org though :)) and I'll try to sort it out. Thanks all, 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=.
Re: Oracle/GIS Testers Needed
On Fri, Nov 20, 2009 at 8:26 AM, Karen Tracey wrote: > On Fri, Nov 20, 2009 at 1:14 AM, Alex Gaynor wrote: >> >> Hey all, >> >> Russ and I have been working on getting the multi-db work ready for >> merge (final stretch here hopefully!), and I just ported the Oracle >> backend to the slightly updated backend arcitecture so it could use >> some testers. If you've got an Oracle setup and can run some tests >> that would be great. You can grab the code here: >> >> http://github.com/alex/django/tree/multiple-db >> >> Make sure you use the multiple-db branch. I understand running the >> tests under Oracle can be a bit slow, so perhaps start by just running >> the "queries" tests, if they fail please reply with the complete >> tracebacks and such here, otherwise if you have the time a shot at >> running the full test suite would be great. >> > > The queries test ran OK once I removed: > > from django.db.backends.oracle import query > > from django/db/backends/oracle/base.py > > I guessed based on the fact that django/db/backends/oracle/query.py was > removed in the last commit that the import was leftover from a > restructuring. I am not sure but it looks like there may also be some other > dead stuff referencing this query module (the query_class method in > DatabaseOperations?), but I did not touch that, just removed that one > import. > > I've got the full suite running now, but that will take a while. > > So far I am testing with just Oracle backend specified. The last time I > tested this branch I also had a test config that specified multiple dbs -- a > default and an extra one. Not sure if you wanted to test that at this point > so I started with the simpler one. > > Karen > > -- > > 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=. > Just running the Oracle tests is enough for now. I've fixed the error you spotted with the stray import left over and pushed that to github. Thanks, 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=.
Re: Oracle/GIS Testers Needed
On Fri, Nov 20, 2009 at 11:03 AM, ben wrote: > Hi Alex, > > I have oracle at work with all versions from 9i to 11. I'd be happy to > run the tests on all of those verisons. I wonder if I could ask a > small favour in return though: > > In our organisation we have a lot of legacy date/time data modeled as > the year 0001-01-01 and then the time in situations where the time is > all we're interested in. This is currently causing a headache due to > http://code.djangoproject.com/ticket/10866 which has a patch and is > ready for checkin. The patch is basically a one character change to > datetime_safe.py which zero pads dates with year < 1000. Would you > mind fixing it? > > Cheers, > Ben > > On Nov 20, 3:17 pm, Alex Gaynor wrote: >> On Fri, Nov 20, 2009 at 8:26 AM, Karen Tracey wrote: >> > On Fri, Nov 20, 2009 at 1:14 AM, Alex Gaynor wrote: >> >> >> Hey all, >> >> >> Russ and I have been working on getting the multi-db work ready for >> >> merge (final stretch here hopefully!), and I just ported the Oracle >> >> backend to the slightly updated backend arcitecture so it could use >> >> some testers. If you've got an Oracle setup and can run some tests >> >> that would be great. You can grab the code here: >> >> >>http://github.com/alex/django/tree/multiple-db >> >> >> Make sure you use the multiple-db branch. I understand running the >> >> tests under Oracle can be a bit slow, so perhaps start by just running >> >> the "queries" tests, if they fail please reply with the complete >> >> tracebacks and such here, otherwise if you have the time a shot at >> >> running the full test suite would be great. >> >> > The queries test ran OK once I removed: >> >> > from django.db.backends.oracle import query >> >> > from django/db/backends/oracle/base.py >> >> > I guessed based on the fact that django/db/backends/oracle/query.py was >> > removed in the last commit that the import was leftover from a >> > restructuring. I am not sure but it looks like there may also be some other >> > dead stuff referencing this query module (the query_class method in >> > DatabaseOperations?), but I did not touch that, just removed that one >> > import. >> >> > I've got the full suite running now, but that will take a while. >> >> > So far I am testing with just Oracle backend specified. The last time I >> > tested this branch I also had a test config that specified multiple dbs -- >> > a >> > default and an extra one. Not sure if you wanted to test that at this >> > point >> > so I started with the simpler one. >> >> > Karen >> >> > -- >> >> > 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=. >> >> Just running the Oracle tests is enough for now. I've fixed the error >> you spotted with the stray import left over and pushed that to github. >> >> Thanks, >> 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=. > > > I'm not familiar with that ticket, nor the issues surrounding it, so I'd be uncomfortable applying a patch in any event, further that ticket isn't specific to my branch so it should go through the normal process of being committed to trunk, then I'll happily merge it in. Thanks for offering to run the tests! 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=.
Re: Oracle/GIS Testers Needed
On Fri, Nov 20, 2009 at 3:56 PM, Karen Tracey wrote: >> Just running the Oracle tests is enough for now. I've fixed the error >> you spotted with the stray import left over and pushed that to github. > > I get 6 failures and 26 errors but I do not know if any of them have > anything to do with multidb. The output is here: > > http://pastebin.com/m2c763672 > > By contrast on trunk I get 7 failures and 26 errors: > > http://pastebin.com/mf7c57a6 > > The unable to create INITIAL extent errors are new -- I've not seen them > before, but I am getting some on trunk as well as multidb (though more on > multidb). I get the impression it may mean my install has some limits on > how big things can grow, and tests are now exceeding those limits. Not > sure, and I don't have time to spend on trying to figure it out right now. > > Nor do I have time to see which failure goes away with multidb, sorry -- so > I figured I'd just post out the results and you can take a look if you think > it would be useful. > > Karen > > -- > > 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=. > Thanks! Unfortunately i have basically no idea what any of those Oracle bugs mean. However, the few non-frightening errors I saw all also appeared on trunk, so I guess my refactor basically didn't break anything. 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=.
Re: Oracle/GIS Testers Needed
On Fri, Nov 20, 2009 at 10:52 PM, Justin Bronn wrote: > >> For GIS I'm fairly certain that's broken, however I'm not quite setup >> for running the GIS tests yet, therefore if you're set up for it and >> can run the tests please just reply with your tracebacks here >> (preferably with them on a pastebin like paste.pocoo.org though :)) >> and I'll try to sort it out. > > Yes, multi-db is seriously broken with GIS on all backends (it'd be > pointless to list all the errors here). Basically, the massive shift > of `Query` internals to `SQLCompiler` is the root of the problem -- > there needs to be a corresponding `GeoSQLCompiler` with `GeoQuerySet` > and `GeoQuery` wired to use it accordingly. I'll try to look at it in > more detail this weekend and see if I can sketch out a better idea of > what needs to be done, but so far it's looking "non-trivial." > > -Justin > > -- > > 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=. > > > Thanks for taking a look Justin. I won't have time to look into it myself this weekend, but if you have any questions feel free to ask here on IRC and I can try to help. Otherwise I will have time this coming week and can hopefully start digging into this, as it's probably the single most important tihng to fix up. 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=.
Re: Feedback on ticket 7777
On Wed, Nov 25, 2009 at 12:15 PM, thebitguru wrote: > Anyone? > > On Nov 23, 6:38 pm, thebitguru wrote: >> Hi, >> >> Can I please get some feedback on this ticket? I am hoping that we >> can get this in soon. >> >> http://code.djangoproject.com/ticket/ >> >> Thanks, >> Farhan > > -- > > 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. > > > Please be patient. At least in the US it's thanksgiving time so I imagine most of the American committers are busy, plus this list has been pretty low traffic the last few days, no one is ignoring your message, people are just busy. 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: Oracle/GIS Testers Needed
On Thu, Nov 26, 2009 at 1:21 AM, Jani Tiainen wrote:
> On Fri, 2009-11-20 at 01:14 -0500, Alex Gaynor wrote:
>> Hey all,
>>
>> Russ and I have been working on getting the multi-db work ready for
>> merge (final stretch here hopefully!), and I just ported the Oracle
>> backend to the slightly updated backend arcitecture so it could use
>> some testers. If you've got an Oracle setup and can run some tests
>> that would be great. You can grab the code here:
>>
>> http://github.com/alex/django/tree/multiple-db
>>
>> Make sure you use the multiple-db branch. I understand running the
>> tests under Oracle can be a bit slow, so perhaps start by just running
>> the "queries" tests, if they fail please reply with the complete
>> tracebacks and such here, otherwise if you have the time a shot at
>> running the full test suite would be great.
>>
>
> I did ran full test suite. First at maximum tablespace size must be
> set bit over 100MB (I changed it to 200MB but in tests I had peak of
> 102MB)
>
> And then bunch of interesting errors:
>
> ==
> ERROR: Multi-db fixtures are loaded correctly
> --
> Traceback (most recent call last):
> File
> "/home/jtiai/src/django/multidb/tests/regressiontests/multiple_database/tests.py",
> line 467, in test_fixture_loading
> title="Pro Django"
> File "/usr/lib/python2.6/unittest.py", line 336, in failUnlessRaises
> callableObj(*args, **kwargs)
> File "/home/jtiai/src/django/multidb/django/db/models/query.py",
> line 300, in get
> num = len(clone)
> File "/home/jtiai/src/django/multidb/django/db/models/query.py",
> line 77, in __len__
> self._result_cache = list(self.iterator())
> File "/home/jtiai/src/django/multidb/django/db/models/query.py",
> line 234, in iterator
> compiler = self.query.get_compiler(using=self.db)
> File "/home/jtiai/src/django/multidb/django/db/models/sql/query.py",
> line 148, in get_compiler
> connection = connections[using]
> File "/home/jtiai/src/django/multidb/django/db/utils.py", line
> 68, in __getitem__
> self.ensure_defaults(alias)
> File "/home/jtiai/src/django/multidb/django/db/utils.py", line
> 54, in ensure_defaults
> raise ConnectionDoesNotExist("The connection %s doesn't exist" %
> alias)
> ConnectionDoesNotExist: The connection other doesn't exist
>
> ==
> ERROR: Queries are constrained to a single database
> --
> Traceback (most recent call last):
> File
> "/home/jtiai/src/django/multidb/tests/regressiontests/multiple_database/tests.py",
> line 100, in test_basic_queries
> published=datetime.date(2009, 5, 4))
> File "/home/jtiai/src/django/multidb/django/db/models/query.py",
> line 315, in create
> obj.save(force_insert=True, using=self.db)
> File "/home/jtiai/src/django/multidb/django/db/models/base.py",
> line 429, in save
> self.save_base(using=using, force_insert=force_insert,
> force_update=force_update)
> File "/home/jtiai/src/django/multidb/django/db/models/base.py",
> line 442, in save_base
> connection = connections[using]
> File "/home/jtiai/src/django/multidb/django/db/utils.py", line
> 68, in __getitem__
> self.ensure_defaults(alias)
> File "/home/jtiai/src/django/multidb/django/db/utils.py", line
> 54, in ensure_defaults
> raise ConnectionDoesNotExist("The connection %s doesn't exist" %
> alias)
> ConnectionDoesNotExist: The connection other doesn't exist
>
> ==
> ERROR: Objects created on the default database don't leak onto other
> databases
> --
> Traceback (most recent call last):
> File
> "/home/jtiai/src/django/multidb/tests/regressiontests/multiple_database/tests.py",
> line 34, in test_default_creation
> Book.objects.get(title="Pro Django")
> File "/home/jtiai/src/django/multidb/django/db/models/manager.py",
> line 119, in get
> return self.get_query_set().get(*args, **kwargs)
> File "/home/jtiai/src/django/multidb/django/db/models/query.py",
> line 307, in get
> % (self.model._meta.object_name, num, kwargs))
> MultipleObjectsReturned: get() returned more than one
Re: Oracle/GIS Testers Needed
On Thu, Nov 26, 2009 at 1:42 AM, Jani Tiainen wrote:
> On Thu, 2009-11-26 at 01:28 -0600, Alex Gaynor wrote:
>
>>
>> Thanks for taking the time to run all of those! All of those
>> ConnectionDoesNotExist errors come from the fact that the multidb
>> tests expect you to have more than 1 DB set up in your settings file,
>> the rigth solution here is probably to just fail right away, instead
>> of attempting to run each individual test which can produce some
>> confusing failures. As for the other errors I'm not sure what's a
>> consequence of my work, and what's an existing condition. If you
>> could run the trunk tests (with your modification for memory) and see
>> what the result is that would be awesome. Any new errors are
>> obviously regressions and should be fixed.
>>
>> Alex
>>
>
> I didn't have to run anything, that what computers are for..? :)
>
> Could you provide sample DATABASES connection definition for multidb
> tests so I could rerun all that fancy stuff correctly.
>
> --
>
> Jani Tiainen
>
>
>
> --
>
> 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.
>
>
>
DATABASES = {
"default": {
# your settings here
},
"other": {
"ENGINE": "sqlite3",
"NAME": ":memory:",
}
}
Is all you need (don't bother rerunning all of the tests with these
settings, the only ones affected are the multiple_database ones).
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: smart if tag
On Sat, Nov 28, 2009 at 11:40 AM, Luke Plant wrote:
> Hi all,
>
> I started work replacing Django's if with the "smart-if" template tag
> by Chris Beaven ( http://www.djangosnippets.org/snippets/1350/ )
>
> Of course, it is not as simple as it looks...
>
> 4 issues:
>
> 1) Handling non-existent variables
> ==
>
> The current smart-if does not handle the case of non-existent
> variables like Django does. (For example, something like
>
> {% if foo or bar %}
>
> when one of foo or bar is not defined in the context.)
>
> To do this properly, I think the best approach would be something like
> "almost three valued logic", which would work as follows:
>
> 1) variables that don't exist are represented by Null
> 2) all operators return either True or False, never Null
> 3) for 'not', 'and' and 'or', Null effectively acts like False
> (so "not Null" == True, "Null or True" == True etc)
> 4) for all comparison operators, if either argument is Null then
> the result is False e.g. "Null == Null" is False
> "Null > 1" is False, "Null <= 1" is False, except
> "!=", which should return true if either value is Null.
>
> Any comments on this approach? I've started to implement this, and it
> works OK so far, just needs a bit more work.
>
Wouldn't that be a break from how {% ifequal %} works? Unless I'm
mistaken if you have a nonexistant value there it becomes None, which
is equal to None.
> 2) TEMPLATE_STRING_IF_INVALID breaks everything
> ===
>
> The smart 'if' tag allows for filters:
>
> {% if articles|length >= 5 %}
>
> To achieve this, it puts its arguments through FilterExpression. If
> settings.TEMPLATE_STRING_IS_INVALID is not an empty string, this means
> that:
>
> {% if foo %}blah{% endif %}
>
> will render 'blah' instead of '' if 'foo' is not in the context. This
> causes test failures at the moment. We could change the tests, but
> that is a backwards incompatibility, and it highlights a fundamental
> change in the behaviour of {% if %}, which basically makes
> TEMPLATE_STRING_IF_INVALID useless for even its stated purpose of
> debugging, because the logic of a template will now be changed.
>
I'm almost positive Malcolm did some refactoring in this area that
lets you get something other than TEMPLATE_STRING_IF_INVALID for an
invlaid FilterExpression.
> Personally, I care nothing for TEMPLATE_STRING_IF_INVALID, as there
> are other things that it breaks, and I never use it. But obviously I
> can't just think of myself here.
>
> If there was an easy solution that didn't change the behaviour of the
> if tag in this case that would be great, but I can't see one.
>
> 3) Behaviour of 'x and b or y'
> ==
>
> Previously this was a syntax error. In Chris's code, it is fine and
> works like Python. I would vote for keeping the smart-if as it is, as
> I don't see the value of complicating the implementation to disallow
> something that could be useful sometimes.
>
+1 on allowing that.
> 4) Behaviour of 'not'
> =
> Current Django will interpret 'not' as a variable if there is no
> ambiguity e.g.
>
> {% if not %}blah{% endif %}
>
> This is not documented, but the behaviour is specified in detail in
> the tests, so changing it would be a backwards incompatibility. The
> smart-if is different (the above is a syntax error), and I suspect
> that making the smart-if behave like current Django could complicate
> things a lot.
>
> IMO, current Django behaviour here is complete misfeature! I don't
> know of any other language where keywords can be treated as variables
> if the keyword doesn't make sense in that position...
>
It's kind of wacky behavior, agreed. But if should be sort of trivial
to implement right? Just if len(bits) == 1 and bits[0] == "not". Or
is this expected to work in cases like "if a and not". If the latter
is expected to work than it'll be a pain I think.
> Regards,
>
> Luke
>
> --
> "He knows the way I take: when he has tried me, I shall come forth
> as gold" (Job 23:10).
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>
Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
Django Developed Sprint in Chicago, January 9-10
Hello all, On Janaury 9-10 in Chicago we'll be holding a development sprint for Django. This sprint will focus primarily on bugfixing for Django's upcoming 1.2 release. No prior experience is needed, there'll be plenty of people there to help you get started! More information can be found here: http://code.djangoproject.com/wiki/Sprint20101Chicago . If you're interested/planning on showing up just add yourself to the list. Everyblock has graciously offered up their offices for our use. Hope to see you there, 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: Session/cookie based messages (#4604)
On Thu, Dec 3, 2009 at 12:58 AM, Tobias McNulty wrote: > > > On Tue, Dec 1, 2009 at 4:35 PM, Luke Plant wrote: >> >> I just converted some code, and the API seems good to me. I had one >> issue, which was the fact that I had some code which only had access >> to the User object, and not the request object, which had to be re- >> plumbed. The only place this change will be an issue is where it is >> difficult to do that (e.g. if your code is being called from somewhere >> else which you can't change). There is no reason this should hold us >> back - storing messages on the User is really a hack, and if people >> have a problem with not being able to do it any more (i.e. in Django >> 1.4), they can use other hacks like storing the request in threadlocal >> storage. > > *gasp* Did I really just hear a core committer condoning threadlocals? > Storing messages on the user was bad, but not that bad. :) > >> >> The simplest solution is to catch the exception in the generic views. >> Another option is to add a 'fail_silently' keyword argument, >> defaulting to False, like the mail sending API. It would need to be >> added to all the shortcut functions, and used in the generic views and >> anywhere that you cannot rely on there being a current authenticated >> User. Docs should include something about it being intended for re- >> usable apps. > > Good catch. fail_silently sounds good to me. I'll add. > > Tobias > -- > Tobias McNulty > Caktus Consulting Group, LLC > P.O. Box 1454 > Carrboro, NC 27510 > (919) 951-0052 > http://www.caktusgroup.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. > I haven't been paying as much attention to this thread as I should be :(. However, I just read through the diff that was uploaded, and I'm curious why the decision to go with functions with APIs like messages.info(request, msg). Instead of request.messages.info(msg). The latter reads far better to me. Thanks, 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: Multiple database support: Request for feedback and testing
On Fri, Dec 4, 2009 at 2:41 PM, Paul McLanahan wrote:
> What will be the default action of manage.py syncdb (without the
> --database option)? Will it create all tables on all DBs, or just use
> "default"? The former would be useful for the simple replication use
> case, but wasteful for partitioning, and the latter could get tiresome
> unless there is a "--database all" option of which I'm unaware.
>
> I also don't see anywhere in the proposed docs where one could specify
> "app -> db" or "app.model -> db" mappings. Without some mechanism for
> such mapping, I'm afraid the partitioning case will become error prone
> and verbose, both with manage.py commands, and in app code. I'd hate
> to have to refactor all of my app's views if I moved some tables to a
> new server. Not having such mappings will also require a refactor of
> many of the views in existing distributed apps to become "multi-db
> enabled" if they don't already accept a QuerySet as an argument (isn't
> necessarily a bad thing, but could delay multi-db usefulness). Moving
> this problem to settings should (operative word) keep multi-db app
> related modification to a minimum, and thus not split all available
> apps into supporting and non-supporting categories. It could also
> greatly ease deployment if one didn't partition in dev, but did in
> staging and production. And this would go a long way toward fixing the
> Admin issue for the partitioning case, and for replication most will
> only need the admin on the default db anyway.
>
> The mappings could be as simple as a new key on the DATABASES dict:
>
> DATABASES = {
> 'default': {
> 'BACKEND': 'django.db.backends.sqlite3',
> 'NAME': 'mydatabase',
> },
> 'stuff': {
> 'BACKEND': 'django.db.backends.sqlite3',
> 'NAME': 'myotherdatabase',
> 'PINNED': ['myapp', 'someapp.model'],
> },
> }
>
> I thought I saw some discussion of this type of thing a while back.
> Was a mechanism for this delayed, removed, undocumented, or am I just
> missing something?
>
> Thanks,
>
> Paul
>
> --
>
> 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.
>
>
>
syncdb only syncs the default database by default.
We will not be adding a setting to pin an application/model to a
specific database. We have already removed the Meta.using option. If
you want to pin an application to a specific database it's fairly
trivial to add a manager and override the save() method to use a
specific DB. Our goal is to design a good long term API for having a
flexible way to define exactly what DB any query goes to, and I
personally have no interest in seeing short term stopgap APIs
implemented.
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: smart if tag
The undcoumented scanner class in the regex module may interest you: http://code.activestate.com/recipes/457664/ Alex On Sun, Dec 6, 2009 at 3:32 AM, SmileyChris wrote: > Because that link intrigued me, I challenged myself to write my own > generic lexer & parser based on what I had read: > http://gist.github.com/250128 > > > > On Dec 6, 2:07 pm, Luke Plant wrote: >> On Saturday 05 December 2009 20:09:21 Luke Plant wrote: >> >> > I'm not likely to able to look at this before Tuesday. If anyone >> > wants to look at it, I think the right approach is something like >> > the following: >> >http://effbot.org/zone/simple-top-down-parsing.htm >> > (without the globals, obviously, they can be converted to instance >> > variables/methods). >> >> Cancel that - I unexpectedly had free time this evening, and I >> implemented this. It's a nice replacement I think (credit to Vaughan >> Pratt and Fredrik Lundh for the basic approach and Python >> implementation respectively). The new implementation is pretty much >> the same length as the old one, and hopefully easier to read, with a >> much smaller core parser. Precedence is specified directly, rather >> than implicitly, so it's much easier to check that it's the same as >> Python's. >> >> Latest patch attached to this e-mail. >> >> Regards, >> >> Luke >> >> -- >> "Idiocy: Never underestimate the power of stupid people in large >> groups." (despair.com) >> >> Luke Plant ||http://lukeplant.me.uk/ >> >> smartif_8.diff >> 27KViewDownload > > -- > > 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. > > > -- "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: Sprint issue tracking / triaging
On Mon, Dec 7, 2009 at 4:46 PM, Jeremy Dunck wrote: > Hey all, > I was wondering if I could do anything to streamline applying > sprint-created patches. > > Obviously, I can do triaging and provide feedback on patches. Can > I be blessed to say "Ready for checkin"? > > What else can I do? I think getting patches which are actually > ready to be committed quickly will help sprinters be motivated and > want to participate in future sprints. > > -- > > 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. > > > I don't see why normal code review procedures aren't enough. If a patch is RFC it should be marked as such, no sooner, no later than if it were a "regular" patch. Being able to provide feedback in person to new contributers is far more valuable than an *additional* RFC designation IMO. As far as who can mark tickets RFC, I don't know if there's a special "hat" they have to wear, I thought it was just people who are familar with the code, so I think you qualify ;) 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: Django 1.2 progress assessment
On Mon, Dec 7, 2009 at 4:59 PM, Jacob Kaplan-Moss wrote: > Hi folks -- > > According to our timeline, we're at (a bit past, actually) the point > where we need to take a quick look at progress towards 1.2 and decide > whether the current timeline still makes sense. > > Right now, we've completed 4.5 features on the 1.2 priority list: > > * Comment admin actions (Contrib-10). > * Improved CSRF protection (Core-01). > * The first half(ish) of merging multidb (GSoC-05) > * QuerySet.exists() (ORM-10) > * Email backends (Email-01) > > Additionally, a few features are in or close to last-call stage > (multidb and the smarter if tag). > > Our current roadmap calls for large feature freeze on December 22nd, > and a complete freeze on January 26th. > > So the question is: given what we've got done, and guess at what we > will get done, is the current timeline still feasible, or should we > push the timeline? > > My opinion is that we should keep the schedule as-is. The features > we've got done so far aren't all huge and game-changing, but if we > released 1.2 with the features *as they stand right now*, it'd still > make a solid upgrade. If we can indeed get multidb merged, that'll be > a killer feature, but if it's not done I don't want to wait for it. > > Not ever release of Django needs to be a home run; I'd settle for a > base hit every time. > > Thoughts? > > 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. > > > I'd be -1 on delaying. I think having consistant releases is more important than having a grand slam every time. I'll also note that I'm very confident that multi-db will be ready for merge by then, Justin and I (ok mostly Justin) have been working on the GIS stuff, which is the last blocker. I think we've got a great release already (ok I'm biased), and with the next month we'll have to work on smaller features we can work on knocking off lots of little tickets that people care about (remember post developers hit far more small bugs than need huge new features like multidb). Also, you can add template caching (and thread safety), #6262, to the list of features that are almost ready to land (unless Russ's opinion of that patch has taken a nosedive). 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: Django 1.2 progress assessment
On Mon, Dec 7, 2009 at 5:13 PM, Jeremy Dunck wrote: > On Mon, Dec 7, 2009 at 4:03 PM, Alex Gaynor wrote: > >> I'm very confident that multi-db will be ready for merge by then, >> Justin and I (ok mostly Justin) have been working on the GIS stuff, >> which is the last blocker. > > Perhaps I missed the gripping conclusion, but wasn't there some > outstanding work to be done on multi-db's interaction with admin? > > -- > > 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. > > > Without wanting to drag this thread *way* off topic, it was my impression that the conclusion of that discussion was that the existing hooks give you the tools you need to make ModelAdmin's work with your multidb setup (using queryset() and save_mode()), if more is needed to this discussion let's do it in the other thread ;) 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: Sprint issue tracking / triaging
On Tue, Dec 8, 2009 at 12:35 PM, Jeremy Dunck wrote: > On Tue, Dec 8, 2009 at 11:27 AM, mrts wrote: > ... >> I have thought about the process a bit and even wrote some >> helper code. >> >> Unfortunately I fell ill and haven't fully recovered (and am >> therefore horribly off-schedule with my work), so I haven't >> had the chance to continue with the effort. >> *Notoriously* bad timing, considering we had a similar >> discussion before and that the sprint is coming up soon. > > Sorry to hear that. The document you linked is a start, but I'm a bit > concerned by this goal: > "to keep the main integration branch as stable as the official trunk > so that it can be used in actual deployments" > > My concern here would be that people become dependent on your > selections for prod, and some of these changes never get merged to > mainline, so that there's functionally a fork in terms of support and > community. > > I guess people will vote with their feet if your queue is really > better. If I do run sprint repos, my specific purpose will be to > provide patchsets for easy integration, but no expectation of people > using those branches for deployment. :-/ > > -- > > 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. > > > Personally I think merge queues ignore where the real work is. Applying a patch (as a diff, or pulling from another repo myself) is a trivial amount of work, and the number of times I have had actual conflicts between 2 patches that were going to be applied is tiny, and where there was a conflict it usually indicated something more fundamental was wrong with the patch. Because of this work to review tickets, provide feedback, and get them into an RFC state is far more important IMO. 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: Sprint issue tracking / triaging
On Tue, Dec 8, 2009 at 1:47 PM, mrts wrote: >> On Tue, Dec 8, 2009 at 12:35 PM, Jeremy Dunck wrote: >> > Sorry to hear that. The document you linked is a start, but I'm a bit >> > concerned by this goal: >> > "to keep the main integration branch as stable as the official trunk >> > so that it can be used in actual deployments" >> >> > My concern here would be that people become dependent on your >> > selections for prod, and some of these changes never get merged to >> > mainline, so that there's functionally a fork in terms of support and >> > community. > > I would really, really want to avoid that. The merge branch would > let people test things out properly, perhaps even in production, and > run a buildbot off it. But the goal of the effort as a whole is just > getting > high-quality reviewed, tested and integrated patches back to Django > trac. > > The wording is just a sketch, seems I have to re-iterate that no > forking in the "bad" sense of the word will occur. The work is meant > for merging back and the main value lies in ticket branches, not in > the merge branch. > > What I envision is the following: > * there's a specific goal and deadline (i.e. fix 10 bugs in 2 weeks), > * sprinters claim tickets in trac, > * sprinters create ticket branches in their corresponding forks of > the Django SVN mirror and work off their branches, > * when the work is ready, it will be reviewed and merged into the > mq by sprint lieutenants, > * buildbots run tests off the mq, > * if all is well, the sprinter uploads the final patch to the > corresponding ticket, > * when the deadline is reached, the tickets that were properly > fixed during the spring are presented to core and will be eventually > merged to SVN trunk simply via the patches in trac. > > As far as I can understand, core has been opposed to taking > more work upon themselves, so the last step should be > effortless, i.e. core can assume that the patch is > well reviewed, tested and non-controversial. > > This workflow is suitable for janitor-type work, not for > epic or controversial changes. > > On Dec 8, 7:40 pm, Alex Gaynor wrote: >> Because of this work to review tickets, provide feedback, and get them >> into an RFC state is far more important IMO. > > Exactly. However, there needs to be a coordinated effort and a > deadline to rally the masses :). The Django community is vast > and certainly full of excellent people who are more than able > to fix a couple of the 1700 open tickets. However, people who > provide patches are few and the patches are mostly > proof-of-concept quality. > > I myself am used to providing somewhat proof-of-concept > quality patches. > > Analyzing the reasons, I noticed that I semi-consciously > am thinking that the trunk changes too much to make > polishing feasible and that a core reviewer "knows better" > and will rewrite it anyway. This attitude doesn't work > within the merge queue workflow, where most of the work > is quickly integrated and thus the contributor needs to pay > more attention to polish. > > So, there's a psychological benefit of the mq besides > the real one. > > Over and out for today, > best, > MS > > -- > > 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. > > > This line of reasoning makes 0 sense IMO. Your argument is people provide sub-par patches because they think trunk moves too quickly, and a committer will need to rewrite it anyways. I've written quite a few patches, I can count on one hand's fingers the number that have needed to be updated for changes in Django itself. Your argument further supposes that by having a target that merges things in more quickly contributors will be more inclined to provide "merge ready" patches since they will in fact be merged. This is completely inconsistent line of reasoning. The reason their patches weren't accepted in the first place was because they weren't good patches, the issue needed a fundamental design decision, or a committer never saw the ticket and patch (I'm ignoring no committers had time, time is going to be a limiting reagent no matter what the solution is). As Russ and others have pointed out elsewhere if a merge queue regularly accepts patches that would be rejected from core it doesn't
Re: QuerySet __contains__
On Tue, Dec 8, 2009 at 8:22 PM, Luke Plant wrote: > Hi all, > > I discovered that QuerySet supports the 'in' operator: > > myset = Articles.objects.filter(foo=bar) > if someobject in myset: > # etc. > > The Python docs I could find imply (but don't state) that if there is > no __contains__() method, but there is __getitem__(), then > __getitem__() is called repeatedly, starting with zero, until > IndexError, and it then does an 'in' on the resulting list. > > That would be very inefficient with a QuerySet, but thankfully it > appears from stepping through a debugger that that doesn't happen if > you define __iter__() (as we have on QuerySet) - it actually calls > __iter__() until StopIteration, and does 'in' on that list. > > This means that the above code is pretty efficient - it does just one > SQL query. > > However, it could be slightly more efficient in some cases, because > the entire QuerySet._result_cache does not necessarily need to be > filled - we can stop if we find a match, saving us the work of > building Model objects that might not be needed. > > The plumbing to do this is all there already - we already optimize the > __nonzero__ method in this way, by getting just the first result. It > can of course be continued if the rest of the set is needed. > > So, I'm thinking of implementing the __contains__ method to do this > optimization. Can anyone think of reasons why not? I think the 'in' > operator is perfectly well defined for QuerySets. > > I don't see this as something that should be documented as a normal > way to do membership tests, as there will often be much more efficient > ways to do it using ORM methods. But, it is something that developers > might do, and with the addition of the 'in' operator in the 'if' tag, > it's something that template authors will be able to do. > > An explicit __contains__ method also protects us against changes in > Python which could produce quite different performance. > > Regards, > > Luke > > -- > "If something is hard, it's not worth doing." (Homer Simpson) > > Luke Plant || http://lukeplant.me.uk/ > > -- > > 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. > > > Sounds like a reasonable optimization, to do, and I can't think of any reasons not to. 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: QuerySet __contains__
On Tue, Dec 8, 2009 at 10:49 PM, Jeremy Dunck wrote: > On Tue, Dec 8, 2009 at 8:38 PM, Luke Plant wrote: >> On Wednesday 09 December 2009 01:52:48 Jeremy Dunck wrote: > ... >>> You could also inspect the item to see if it's an instance of the >>> .model; if not, fast path False. >>> >>> Which leads to a question of edge-case semantics -- "1 in qs" >>> checking for primary key value. Good or bad? >> >> I think it's much better to leave __contains__ just doing an '==' >> check, rather than anything clever which could surprise people. (If >> the developer is doing a test which is always going to return False, >> it's a mistake, not an optimization opportunity). > > I see what you're saying. I got there starting from the thought that > __contains__ should perform a PK query if iteration hasn't started, > rather than filling the results cache. __nonzero__ is O(1), where > "in" would be O(N). > > -- > > 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. > > > I disagree that it should do a PK query in that case. There is precedent for doing it in pure python, even in cases where it is less efficient, such as .count() vs. len(). 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: #12250 Feedback Request
On Wed, Dec 9, 2009 at 11:21 PM, Michael Manfre wrote: > If a middleware throws an exception, it is not possible to catch and > handle that error. Instead it goes straight to the unhandled exception > handler and prevents any process_exception middleware methods from > acting on the exception. I included a patch that shifts the > process_view processing down a line of code to allow middleware > exception handling. > > #12250 http://code.djangoproject.com/ticket/12250 > > Regards, > Michael Manfre > > -- > > 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. > > > This is actually a duplicate of another ticket (who's number I can't recall, but it is in the 6000 range). 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: Deprecating psycopg 1
On Sat, Dec 12, 2009 at 7:02 PM, Jacob Kaplan-Moss wrote: > Hi folks -- > > I'd like to start the process of deprecating and removing support for > psycopg 1. Why? > > * psycopg 2 is better in every way. > * psycopg 1 hasn't been updated since October 2005; it's basically a dead end. > * I don't know anyone using it in production. > * For the couple-three people who *are*, it's now possible (and > reasonably easy) to maintain an external backend. > > I'm proposing the following very predictable timeline: > > Django 1.2 > Use of the "postgresql" backend raises a PendingDeprecationWarning. > > Django 1.3 > Use of the "postgresql" backend raises a DeprecationWarning. > > Django 1.4 > Remove the "postgresql" backend from Django (and put it on > bitbucket/github?) > > Any objections? > > [I'm deliberately not discussing anything regarding the renaming of > the "postgresql_psycopg2" backend. I have a bigger proposal I'd like > to make around that, but that's gonna have to wait for 1.3.] > > 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. > > > +1. psycopg1 is already missing quite a few features from psycopg2 (autocommit, GIS, etc.). 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: Python version roadmap
On Tue, Dec 15, 2009 at 10:15 PM, DULMANDAKH Sukhbaatar wrote: >> Also, we should be adding any plans to drop 2.4, 2.5 etc into the >> internals/deprecation.txt documentation, and we ought to do that >> *before* 1.2 is released, to give as much warning as possible. > > Please note that python 2.4 is default in RHEL5. > > -- > Regards > Dulmandakh > http://www.dulmandakh.com > http://www.twitter.com/dulmandakh/ > > -- > > 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. > > > That's know, but the simple fact remains that that's a really old version of python (over 5 years), and in the larger view we need to be moving towards 2.6 and 3.0. Nobody is required to upgrade. 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: Re: Python version roadmap
On Tue, Dec 15, 2009 at 10:35 PM, wrote: > A word of caution on dropping support of python 2.4: it is still shipped > with RHEL 5 which is supported until 2014 > (http://www.redhat.com/security/updates/errata/). > > -- > > 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. > I highly suggest you read this thread. That was literally discussed in the posts directly above yours. 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: Last call: #11863 (Model.objects.raw)
On Wed, Dec 16, 2009 at 12:08 PM, Jacob Kaplan-Moss wrote:
> On Wed, Dec 16, 2009 at 10:13 AM, Jeremy Dunck wrote:
>> This won't work, because deferred fields are descriptors, and
>> accessing foo.field would run the query.
>>
>> Something you could do is foo.deferred_fields.field_name -> Boolean,
>> but that seems pretty clunky to me.
>
> You can get at this information now if you really need to::
>
> >>> e = Entry.objects.defer('body')[0]
> >>> [f.attname for f in e._meta.fields if f.attname not in e.__dict__]
> ['body']
>
A better approach is, IMO:
>>> [f.name for f in e._meta.fields if
>>> isinstance(e.__class__.__dict__.get(f.attname), DeferredAttribute)]
["body"]
since it more accurately expresses what you're trying to do (also,
it's crazy longer and looks way more serious).
Alex
> But the point is that deferred fields are an optimization. You
> shouldn't need to know which fields are deferred: you should be adding
> ``defer`` as a last-step optimization once you *know* the fields in
> question aren't needed.
>
> IOW, why do I need to inspect the ``Entry`` to figure out what's
> deferred? I just *told you* what's deferred in the previous line.
>
> 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.
>
>
>
--
"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: What do people think about the get_absolute_url proposal?
On Wed, Dec 16, 2009 at 2:02 PM, Mike Malone wrote:
>> The way i see it (which may be wrong), this is not a proposal to make
>> the request object global or replace/refactor the contrib.site app. In
>> fact, some of the use cases mentioned strike me as things that would
>> require overriding the default get_absolute_url method anyway. It
>> seems to me like everyone is arguing over things outside the scope of
>> this proposal.
>
> Actually the fundamental disagreement (as far as I can tell) is over
> whether the absolute URL should be built using information pulled from
> various application settings (Site module, settings file, etc) or
> information pulled from the currently active request.
>
> In my opinion, using the Site module and settings files is damn
> annoying. I never use the Site module, and in my experience having to
> change the "FRONTEND_URL" of your app every time you push to a
> different environment is tedious and a frequent source of subtle
> problems. Moreover, the request information in your current request
> _should_ always be correct. If someone requests a non-canonical URL
> you should redirect (CNAME, 301, etc) to the canonical URL. If your
> load balancer isn't sending the correct headers then the load balancer
> is broken, not Django.
>
> That said, it sounds like there are a number of special cases where it
> would be useful to override these settings. So maybe the best corse of
> action is to try to use the configured Site information and fall back
> on "RequestSite", which uses information from the currently active
> request.
>
> Thoughts?
>
> Mike
>
> --
>
> 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.
>
>
>
I am very strongly against making the request a thread local. We have
used thread locals in a few places (urlconf and i18n are the obvious
ones), and while they don't put a smile on my face they do serve a
very narrow, well defined purpose, in places where it would often be
impossible to get the appropriate context in.
However, I think making the entire request object (or even just the
domain + SSL state) is an incredibly open ended solution that is rife
with potential for abuse.
However, I come bearing a solution!
Instead of having get_url() or whatever the method is named return a
string, have it return a URL object, specifically instantiated with
REQUEST_HOST for it's host value. Then the caller can pass this value
around and when it gets returned to the appropriate place where the
request is in scope it can interpolate it's values into the URL object
appropriately. This may necessitate adding a template filter ({{
obj.get_url|interpolate_request:request }}).
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: What do people think about the get_absolute_url proposal?
On Wed, Dec 16, 2009 at 2:53 PM, Mike Malone wrote:
> On Wed, Dec 16, 2009 at 11:10 AM, Alex Gaynor wrote:
>> On Wed, Dec 16, 2009 at 2:02 PM, Mike Malone wrote:
>>>> The way i see it (which may be wrong), this is not a proposal to make
>>>> the request object global or replace/refactor the contrib.site app. In
>>>> fact, some of the use cases mentioned strike me as things that would
>>>> require overriding the default get_absolute_url method anyway. It
>>>> seems to me like everyone is arguing over things outside the scope of
>>>> this proposal.
>>>
>>> Actually the fundamental disagreement (as far as I can tell) is over
>>> whether the absolute URL should be built using information pulled from
>>> various application settings (Site module, settings file, etc) or
>>> information pulled from the currently active request.
>>>
>>> In my opinion, using the Site module and settings files is damn
>>> annoying. I never use the Site module, and in my experience having to
>>> change the "FRONTEND_URL" of your app every time you push to a
>>> different environment is tedious and a frequent source of subtle
>>> problems. Moreover, the request information in your current request
>>> _should_ always be correct. If someone requests a non-canonical URL
>>> you should redirect (CNAME, 301, etc) to the canonical URL. If your
>>> load balancer isn't sending the correct headers then the load balancer
>>> is broken, not Django.
>>>
>>> That said, it sounds like there are a number of special cases where it
>>> would be useful to override these settings. So maybe the best corse of
>>> action is to try to use the configured Site information and fall back
>>> on "RequestSite", which uses information from the currently active
>>> request.
>>>
>>> Thoughts?
>>>
>>> Mike
>>>
>>> --
>>>
>>> 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.
>>>
>>>
>>>
>>
>> I am very strongly against making the request a thread local. We have
>> used thread locals in a few places (urlconf and i18n are the obvious
>> ones), and while they don't put a smile on my face they do serve a
>> very narrow, well defined purpose, in places where it would often be
>> impossible to get the appropriate context in.
>>
>> However, I think making the entire request object (or even just the
>> domain + SSL state) is an incredibly open ended solution that is rife
>> with potential for abuse.
>>
>> However, I come bearing a solution!
>>
>> Instead of having get_url() or whatever the method is named return a
>> string, have it return a URL object, specifically instantiated with
>> REQUEST_HOST for it's host value. Then the caller can pass this value
>> around and when it gets returned to the appropriate place where the
>> request is in scope it can interpolate it's values into the URL object
>> appropriately. This may necessitate adding a template filter ({{
>> obj.get_url|interpolate_request:request }}).
>
> How's that different than the current situation, where we return an
> absolute URL reference that can be converted into an absolute URL
> using request.build_absolute_uri?
>
> Mike
>
>>
>> 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.
>>
>>
>>
>
> --
>
> You received this message because you are subscribed to the Google Groups
&
Re: What do people think about the get_absolute_url proposal?
On Wed, Dec 16, 2009 at 4:51 PM, SmileyChris wrote:
>
>
> On Dec 17, 8:57 am, Alex Gaynor wrote:
>> On Wed, Dec 16, 2009 at 2:53 PM, Mike Malone wrote:
>> > How's that different than the current situation, where we return an
>> > absolute URL reference that can be converted into an absolute URL
>> > using request.build_absolute_uri?
>>
>> It allows an object to return a URL that already has it's domain
>> defined (as might happen for a SaaS site with custom subdomains).
>>
>
> build_absolute_uri allows that already.
>
>>>> r = HttpRequest()
>>>> r.META['SERVER_NAME'] = 'test.com'
>>>> r.META['SERVER_PORT'] = '80'
>>>> r.build_absolute_uri('fish')
> 'http://test.com/fish'
>>>> r.build_absolute_uri('//fish.com/fish')
> 'http://fish.com/fish'
>>>> r.build_absolute_uri('https://fish.com/fish')
> 'https://fish.com/fish'
>
> --
>
> 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 mistake. I have to admit I'm rather confused about what the
discussion is at this point :/
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: Final call for feedback: Multi-db
On Fri, Dec 18, 2009 at 12:41 PM, Brett Hoerner wrote:
> I'm not sure if 1.2 intended to fully support read-slaves, but I'll
> post this quick anyway as we've just run into it while trying to
> upgrade at DISQUS.
>
> You might think that having support for multiple databases implies
> that using a read-slave would Just Work, and that's mostly true.
> There's one edge case I've run into when you try to relate objects
> using instances created from different mirrors of the same database.
> Because of the checks against instance._state.db you can't select an
> object from a read-slave and assign it to a foreign key relation (and
> probably other relations) on the master, even though you know this is
> a mirror and not a different database.
>
> Here's a quick code example: http://dpaste.org/Bozd/
>
> The only solution I've thought of (and I haven't thought long, I just
> ran into this) is another database setting where you could tell Django
> that this DB is a mirror of another (by name?) so that
> instance._state.db on a read-slave created object actually holds the
> value of DATABASES['that_read_slave']['mirror_of'] (or whatever key).
> In other words a User selected from 'read_slave' might actually have a
> user_instance._state.db value of 'default', because that's it's true
> home, and any relations should be compared to that.
>
> I would think read-slaves would be a pretty common application of
> multidb, but I can only speak to our use case. I know it's a bit late
> in the game, but we'll have to work up our own local fix or go with a
> proper one before we can deploy 1.2. And to think I was so happy
> about how many local Django patches I was able to remove going from
> 1.0->1.2. ;)
>
> Amazing work, Alex & Russell, many thanks.
>
> Regards,
> Brett
>
>
>
> On Dec 17, 11:43 pm, Russell Keith-Magee
> wrote:
>> Hi all,
>>
>> This is a second and final call for feedback on the multidb branch.
>>
>> Barring any objections or the discovery of major problems, my
>> intention is to commit this early next week, hitting the alpha 1
>> feature deadline by the skin of our collective teeth :-)
>>
>> There has been one big change since the last call for feedback -
>> thanks to Justin Bronn, GIS is now fully multi-db compliant.
>>
>> There have also been a couple of small changes - mostly integrating
>> the contrib applications with multidb features. For example, the
>> contenttypes app now maintains a cache of content type objects that is
>> multi-db aware.
>>
>> The only really visible change is a new 'db_manager()' operator on
>> Managers. This is used to obtain a Manager instance that is bound to a
>> specific database. This is required because:
>>
>> Author.objects.using('foo')
>>
>> will return a QuerySet that is bound to foo - however, methods like
>> User.objects.create_user(...) and
>> Permission.objects.get_by_natural_key(...) are on the Manager, not the
>> QuerySet.
>>
>> So, you can now call:
>>
>> Author.objects.db_manager('foo')
>>
>> which will return a Manager (Author's default manager) that is bound
>> to the foo databse. Subsequent calls to using() can change this
>> binding if necessary.
>>
>> At the last call for feedback, questions were raised about admin
>> support. I've done some investigation, and it turns out that you can
>> write ModelAdmin definitions that bind a model to a different
>> database. I'm in the process of documenting the exact steps that are
>> required. Coming up with a pretty integration layer with admin will be
>> left for Django 1.3, when we will be addressing the issue of how to
>> provide a good public interface to multidb for common use cases
>> (master/slave, sharding, etc)
>>
>> As always, the code is available in the multi-db SVN branch:
>>
>> http://code.djangoproject.com/svn/django/branches/soc2009/multidb/
>>
>> or from Alex's github branch:
>>
>> http://github.com/alex/django/tree/multiple-db
>>
>> Again, any and all feedback welcome.
>>
>> 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.
>
>
>
Thanks for the feedback Brett (sorry I didn't get back to your original email).
I think you're right that this is an important usecase, any case where
identical pks indicate mirroring across different DBs this will fail.
I'm wondering if perhaps the most prudent thing to do would be to
simply remove this check. The end result will be you'll get an
integrity error on Postgres/Oracle when you try to save (and SQLite
and MySQL will just let you do whatever).
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
Re: Call for feedback: django.utils.signed and signed cookies
On Tue, Dec 22, 2009 at 12:22 AM, Russell Keith-Magee
wrote:
> On Tue, Dec 22, 2009 at 8:00 AM, Simon Willison
> wrote:
>> I've made some changes based on the feedback in this thread:
>>
>> http://github.com/simonw/django/commit/802952bbb8b763e65ee545c6a8f39524b20e147c
>> "Use sha('signer' + secret_key + salt) to derive the key for use in
>> the
>> signature() method, addressing feedback from the django-developers
>> list"
>>
>> The default signature() method now looks like this:
>>
>> def signature(self, value, salt=''):
>> # Derive a new key from the SECRET_KEY, using the optional
>> salt
>> key = sha_constructor('signer' + self.key + salt).hexdigest()
>> return base64_hmac(value, key)
>>
>> The secret key (self.key here) is now never used directly. Instead, a
>> sha1 hash of the salt 'signer' plus the secret key plus any additional
>> salt is used as the key for the signature. sha1 is used here as
>> protection against weird key length extension attacks (like the one
>> that affected the Flickr API recently).
>>
>> http://github.com/simonw/django/commit/4ed44c2bce5000d6c78c3a26b84d08f636b3589c
>> "RAISE_ERROR now capitalised to emphasize that it is a constant"
>>
>> http://github.com/simonw/django/commit/20f3a693b99ec6af0f91eecb31046e8a07dc7151
>> "Signed cookies now automatically include the name of the cookie as
>> part of the salt"
>>
>> http://github.com/simonw/django/commit/68c52f0b995447d93bce1db486b23a27b918da73
>> "Moved get_cookie_signer in to utils.signed"
>>
>> New patch is attached to the ticket. Is there anything else I need to
>> address before checking it in?
>
> As far as the patch itself is concerned, looks good to me. My only
> other request would be a serving of dogfood - if we're going to
> include a signed cookie module, it would be nice to prove that it can
> actually be used by actually using it.
>
> Russ %-)
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-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.
>
>
>
As an FYI Eric Florenzano has said that he asked a friend of his,
Matthew Dempsky, to take a look at this (from a security perspective),
he's the gent who found the security hole in djbdns.
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: Congratulations Alex and Russell on committing multidb!
On Tue, Dec 22, 2009 at 2:44 PM, Peter wrote: > > I just noticed and can only agree... nice work. > > //Peter > > On Tue, Dec 22, 2009 at 18:27, Simon Willison > wrote: >> >> And a big congratulations to all involved. Here's the changeset log >> (on GitHub since Trac seems not to like being linked to at the >> moment): >> >> >> http://github.com/django/django/commit/836d297e68d6a63103780295adebf6eaf6779611 >> >> And here's the documentation: >> >> http://docs.djangoproject.com/en/dev/topics/db/multi-db/ >> >> Really excited about this - can't wait to start putting it to good >> use. >> >> Cheers, >> >> Simon >> >> -- >> >> 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. > Thanks guys, there are a lot more people than Russ and I who deserve the credit though! 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: Ticket #5025 - truncate filter, why hasn't it been accepted?
On Tue, Dec 29, 2009 at 11:59 PM, John Debs wrote:
>
>
> On Dec 29, 9:08 pm, James Bennett wrote:
>
>> It is built in, though, it's just called "slice". The only thing
>> people seem to offer to differentiate this proposal from the existing
>> filter is that the proposed "truncate" would add an ellipsis at the
>> end, and honestly I'm not really convinced that's a significant enough
>> use case to warrant adding another built-in filter.
>
> For what it's worth, it's something I've wanted (and wondered about)
> for several of my projects, and I've heard the same from others. It
> seems to me that more often than not, developers want an ellipsis when
> truncating strings like that.
>
> I thought about suggesting adding an option to the existing slice
> filter but I really think that's its own use case and that there
> should be a new truncatestring filter that matches the syntax of
> truncatewords.
>
> It's especially unclear to new developers that they should accomplish
> this with slice (and an if statement checking the length of the
> string) - and it's not very DRY. The convenience of having slice is
> undermined by the fact that many aren't clever enough to use it this
> way - it certainly didn't occur to me.
>
> So, +1 to this idea.
>
> John
>
> --
>
> 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 the ellepsis is as simple as:
{{ foo|slice:":100" }}{% if foo|length > 100 %}...{% endif %}
Given that the recent expansion of the {% if %} tag makes that so easy
I don't think it's a compelling reason to add a {% truncate %} tag.
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: Ticket #5025 - truncate filter, why hasn't it been accepted?
On Wed, Dec 30, 2009 at 10:53 AM, Nic Pottier wrote:
> On Dec 29, 10:01 pm, Alex Gaynor wrote:
>> Adding the ellepsis is as simple as:
>>
>> {{ foo|slice:":100" }}{% if foo|length > 100 %}...{% endif %}
>>
>> Given that the recent expansion of the {% if %} tag makes that so easy
>> I don't think it's a compelling reason to add a {% truncate %} tag.
>>
>> Alex
>
> Thank you for acknowledging that slice is not at all the same thing as
> a real truncate. Having that kind of {% if %} scattered around your
> templates is exactly the reason we need a filter.
>
> Perhaps the use case just hasn't been explained enough.
> truncate_words is not the same thing, and should indeed be used if you
> are truncating a paragraph of text. truncate comes in when you have a
> URL or filename, which won't have any spaces and you don't want to
> blow off the end of your div or ruin your table cells.
>
> I guess I don't understand the big drawback? There is obviously a
> need, some quick googling finds quite a few independent
> implementations of this filter for Django, plus we have a few patches
> submitted, some IRC logs, and the people who've piped up on this list.
>
> Is there a big overhead I'm not seeing in adding this filter, either
> in performance or maintenance? It certainly seems like a lot of users
> want it, and as others have said, it probably would garner more usage
> than some of the other stranger filters present in core.
>
> -Nic
>
> PS. I agree that smarty's truncate seems like a pretty reasonable spec
> if we really want to do it right:
> <http://www.smarty.net/manual/en/language.modifier.truncate.php>
>
> I'd be perfectly willing to write up a patch to that spec against the
> current code base if I knew it wouldn't languish.
>
> --
>
> 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.
>
>
>
I'd highly recommend watching
http://www.youtube.com/watch?v=tscMnoS4YU8 in it this *exact* question
comes up and Russ, Malcolm, and a few other people discuss the pros
and cons of adding new template tags/filters.
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: Ticket #5025 - truncate filter, why hasn't it been accepted?
Ok, we get it, some people want this feature. I'd like to kindly request that people just saying "+1" stop. The number of people in this thread is minuscule compared to the size of the django user population, trying to extrapolate from 1, 10, or even 100 people in this thread to a large percentage of the community wants this is simply not possible. The video I linked earlier had a critical point that I think a lot of people are missing, adding a single filter may not add a lot to the developer's burden directly but it impacts the perceptions (and realities) of what kinds of things are reasonable for inclusion in core. The simple fact is some people want this, and some don't. Not having this is not an intractable problem for people who need it, in fact it's a trivial one. I don't really care whether this is included or not, but it seems to me that there's very little in terms of new ground in the discussion. 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: Ticket #5025 - truncate filter, why hasn't it been accepted?
On Wed, Dec 30, 2009 at 3:36 PM, dannyr wrote: > > Alex, > > What's the rationale of including truncatewords into the core? How is > truncatewords different to truncate (characters)? > > On Dec 30, 12:29 pm, Alex Gaynor wrote: >> Ok, we get it, some people want this feature. I'd like to kindly >> request that people just saying "+1" stop. The number of people in >> this thread is minuscule compared to the size of the django user >> population, trying to extrapolate from 1, 10, or even 100 people in >> this thread to a large percentage of the community wants this is >> simply not possible. >> >> The video I linked earlier had a critical point that I think a lot of >> people are missing, adding a single filter may not add a lot to the >> developer's burden directly but it impacts the perceptions (and >> realities) of what kinds of things are reasonable for inclusion in >> core. The simple fact is some people want this, and some don't. Not >> having this is not an intractable problem for people who need it, in >> fact it's a trivial one. >> >> I don't really care whether this is included or not, but it seems to >> me that there's very little in terms of new ground in the discussion. >> >> 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. > > > Probably that truncate_words is *slightly* less trivial to implement. Plus it's been there since forever, removing it would be an extremely large backwards compatible change. 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.
Django Development Sprint Reminder -- Chicago January 9-10th
Hi all, This is just a quick reminder that there will be a development sprint for Django on January 9-10th in Chicago at the Everyblock offices. This is just after the major feature freeze so we'll be working on a bunch of smaller features. If you can make it we'd love if you could join us. If you've never contributed to Django before this is the perfect time to start, we'll have plenty of people to help you get started! If you can make it please sign yourself up here: http://code.djangoproject.com/wiki/Sprint20101Chicago (just add your name to the list), and if you can't make it in person we'll all be on IRC so you can sprint with us online as well! Thanks, 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: Finalizing model-validation: ComplexValidator
On Sun, Jan 3, 2010 at 7:31 PM, Honza Král wrote:
> Hi everybody,
>
>
> On Fri, Jan 1, 2010 at 10:30 PM, Joseph Kocherhans
> wrote:
>
>> The ComplexValidator doesn't know in advance if it's going to be used
>> for model validation or form validation. ComplexValidator's get_value
>> method is meant to help with this situation, but it needs to take
>> *both* the dict and obj values to get the value, and as such, it's a
>> little clunky.
>
> We could change this by instantiating the ComplexValidator with obj
> and all_values (or make it a factory for validator callables, anything
> of that sort), so that custom validation code (currently in __call__)
> would just call .get_value('other_field'). It might be tricky too --
> we would basically be passing classes to the field's validator param,
> instantiating them in form/model.clean() and then calling their
> .validate() method (or __call__ing them), but the interface of the
> code itself would be much less clunky.
>
> We would just need to provide a clean interface for defining such
> validator - haven't really thought about this approach so I don't have
> an API proposal ready.
>
What if we had some sort of wrapper class for objs, it could overide
__getattribute__ to return either an attr if it's an obj, or a
subscript if it's a datadict. it seems to me this would solve both
concerns?
Alex
>
>> Here are a few options:
>>
>> 1) Drop ComplexValidator support for 1.2.
>>
>> I think we could come up with a more elegant solution given some
>> usage and time. The branch is still incredibly useful even without
>> ComplexValidator.
>
> Sure, we could do this, I am +0 on this. We need real life use cases
> just to be sure if people want these validators.
>
>> 2) Convert a model to a dict before passing it to ComplexValidator
>> so they always just deal with dicts.
>>
>> This wouldn't address my discomfort with isinstance checks, but it
>> would make writing ComplexValidators a lot less clunky.
>
>
> I am -1 on this since it wouldn't allow people to call methods and
> properties on their models from their validators if they wanted to.
>
>
>>
>> 3) Leave ComplexValidator in as-is.
>>
>> I don't need a whole lot of convincing that this is the way to go.
>> If we come up with a better solution later, ComplexValidator itself
>> would be fairly easy to deprecate.
>
>
> I would like to invite Jacob and Malcolm into this discussion since the API
>
> def my_validator(value, all_values={}, obj=None):
> ...
>
> was initially their idea during DjangoCon 2008 and they had some
> persuasive arguments there.
>
> I decided not to make all validators have this signature to keep the
> option of using a Field without a Form or Model, that's where the need
> to separate these two types of validators arose.
>
>
>> 4) You're awesome idea that has escaped me so far.
>>
>> This will probably start with option 1, then we'd add the feature
>> after the branch is merged, or in the 1.3 timeline.
>
> definitely +1
>
> --
>
> 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.
>
>
>
--
"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: Finalizing model-validation: ComplexValidator
On Sun, Jan 3, 2010 at 7:50 PM, Joseph Kocherhans wrote: > On Sun, Jan 3, 2010 at 7:34 PM, Alex Gaynor wrote: >> >> What if we had some sort of wrapper class for objs, it could overide >> __getattribute__ to return either an attr if it's an obj, or a >> subscript if it's a datadict. it seems to me this would solve both >> concerns? > > I was thinking along similar lines, but with __getitem__ instead, > basically just using a dict interface wrapping a model object, but > that hides the model's methods. Honza makes a good point that those > would be good to have access to. I feel a lot more comfortable > treating a model like a dict than vice-versa, although that's > admittedly rather arbitrary. > > Joseph > > -- > > 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. > > > I'm ambivalent as to which would be prefered, my one concern is people who probably tend to forget that they could do obj["my_method"](), since the syntax appears wonky (unless the methods were proxied by __getattribute__). 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: Final call for feedback: Multi-db
Yes, multiple database support was merged into trunk on December 22:
http://www.djangoproject.com/multidb-changeset/
Alex
On Mon, Jan 4, 2010 at 9:40 AM, Joe wrote:
> Has this code been merged to a 1.2 alpha build somewhere or is the
> multi-db branch still the current release? Only asking because the
> first message in the thread indicated a schedule which meant the code
> would be merged in before EOY and I just want to make sure I'm on the
> right codebase moving forward :)
>
> Thanks,
> Joe
>
> On Dec 23 2009, 4:04 am, Russell Keith-Magee
> wrote:
>> On Wed, Dec 23, 2009 at 1:32 PM, Michael Manfre wrote:
>> > With multiple database defined, what is the expected behavior for
>> > syncdb and the otherdbrelated commands?
>>
>> The management commands all work the same way under multidb - they
>> only ever work on a single database at a time. If you don't specify a
>> database, the 'default' databse is used.
>>
>> > The documentation shows that
>> > it is relatively easy to associate an admin form with a given
>> > database, but is there a way of associated a model or app to a given
>> > database?
>>
>> Yes - ish. If you're working with your own application and models,
>> just define a custom manager for that model. The manager just needs to
>> override get_query_set() and applies a using() modifier:
>>
>> class PersonManager(models.Manager):
>> def get_query_set(self):
>> return super(PersonManager, self).get_query_set().using('other')
>>
>> class Person(models.Model):
>> objects = PersonManager()
>> name = models.CharField(max_length=50)
>> ...
>>
>> Unfortunately, this approach doesn't work for a model in a reusable
>> app - for example, you can't easily push contrib.auth.User to a
>> different database. However, you can just call
>> User.objects.using('other') whenever you want to use the User
>> model.
>>
>> I know this is less than ideal, but the goal for 1.2 was to complete
>> the plumbing and get the important porcelain in place (e.g., using()).
>> The goal for 1.3 is to identify the common end-user use cases for
>> multidb and make some easily exploitable hooks for end-users.
>>
>> 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.
>
>
>
--
"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: Design and code review requested for Django string signing / signed cookies
On Mon, Jan 4, 2010 at 4:53 PM, Luke Plant wrote: > On Monday 04 January 2010 21:45:41 jcampbell1 wrote: > >> I am not that familiar with your framework, but I think a signed >> cookie should use http only cookies by default. There is no valid >> reason for a script to read a cookie that it can't verify. http >> only cookies significantly decrease the surface area of XSS >> attacks. > > I can think of various circumstances where it might be useful and > harmless. For example, if the signed cookie stored the user's login > name, and some client side javascript used the login name for some > convenience feature, like highlighting the login name wherever it > appeared on the page. > > To generalise, the issue of using HttpOnly cookies is orthogonal to > whether they are signed or not, because the value of the cookie can be > used in multiple ways, not all of which will depend on the value being > verified. > > Luke > > -- > "Love is like an hourglass, with the heart filling up as the brain > empties." > > Luke Plant || http://lukeplant.me.uk/ > > -- > > 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. > > > So, thinking out loud here, I know the DSF has a policy of hands of in the development of Django, but I was thinking (out loud) that perhaps it would be sensible for the DSF to hire someone to do a security audit of some of this stuff. I have 0 clue about the particulars of how anything like that works, but it was just a thought that occurred to me. 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: Model validation incompatibility with existing Django idioms
On Wed, Jan 6, 2010 at 4:06 PM, Brian Rosner wrote: > > On Jan 6, 2010, at 2:56 PM, Joseph Kocherhans wrote: >> I had another idea that I think might work out. What if >> ModelForm.validate() only validated fields on the form, like it worked >> before the merge, and ModelForm.save() would automatically validate >> the excluded fields, raising ValidationError if there was a problem? >> Validation for each field would only happen once, it would accommodate >> the commit=False idiom, and it would still ensure that the model >> itself is validated in common usage. > > I like this. It would then provide far superior error messages in cases where > there was real developer error. > > Brian Rosner > http://oebfare.com > http://twitter.com/brosner > > > -- > 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. > > > > I agree with Brian. I also really like the context manager based API, so for 1.3 I think it would be nice to include something like that. 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: Django docs aren't aware custom model save methods need the "using" keyward arg.
On Thu, Jan 7, 2010 at 5:25 PM, j...@jeffcroft.com wrote: >> Are you sending from other email addresses? I only see a few >> occurrences of j...@jeffcroft.com on django-dev, and I haven't seen >> you get destroyed. :-/ Sucks that you feel that way. > > The destruction tends to come via Twitter. :) > > I was half-joking, it's not a big deal. > > -- > 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. > > > > Yep, there's a ticket for this, just an oversight when we did the docs. 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: Porting Django to Python 3
On Tue, Jan 12, 2010 at 10:52 PM, Joshua Partogi wrote: > On Jan 9, 1:02 pm, Russell Keith-Magee wrote: >> On Sat, Jan 9, 2010 at 2:25 AM, Dave wrote: >> > Hello everyone, >> >> > My name is Dave Weber, and I'm a student at the University of Toronto, >> > studying Computer Science. For one of our undergraduate courses led by >> > Greg Wilson (http://www.cs.utoronto.ca/~gvwilson/), myself and a group >> > of 10 other computer science students will be trying to port Django to >> > Python 3. >> >> > Until the end of January, we'll be studying the existing Django code >> > in order to gain an understanding of how the program works. We'll be >> > doing this primarily through architecture documentation and >> > performance profiling. In early February we plan on beginning work on >> > the port. >> >> > A few of us have experience working with Django, and by the end of >> > January we should have a much better understanding of it. I've been in >> > touch with Jacob Kaplan-Moss, who pointed me to this group, and he >> > also provided me with links about contributing to the Django project >> > and Martin van Lowis' port. >> >> > We don't really have any specific questions right now as we're pretty >> > unfamiliar with most of the project at this point in time. However, we >> > are very eager to learn as much as we can, so if you have any advice, >> > warnings, or anything at all to say to us, please feel free! We'd like >> > to hear from all of you as much as possible. >> >> Hi Dave, >> >> Sounds like an interesting project! >> >> My best piece of advice would be to learn to love the test suite. >> Django's test suite may take a long time to run, but it is quite >> comprehensive, and has enabled us to complete several large internal >> refactoring projects with a minimum of impact on the general user >> community. >> >> My other advice would be to get involved in the community. Don't just >> treat your Python 3 port as "your CS project", independent of the rest >> of the world. For example, if your porting efforts discovers a section >> of code that isn't tested (or tested well), or you discover a simple >> fix that will boost performance, don't be a stranger - submit a patch >> and help us make Django better. >> >> This even extends to documentation - if your porting efforts generate >> architecture documentation that might be useful to the general >> community, we'd love to have that contributed back to the community. >> >> Best of luck with your project. I can't wait to see what you come up with :-) >> >> Yours, >> Russ Magee %-) > > Russ, > > Would it be possible if the django core developers to create a python3 > branch in the django svn repository? > > Kind regards, > > -- > http://jobs.scrum8.com | http://twitter.com/scrum8 > > -- > 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. > > > > I'm not a core developer, but my perspective on the matter is, why? Branches in Django's SVN are usually either from core developers or other individuals working on projects specifically endorsed, and mentored by core developers (such as GSOC). As such I think the most sensible course of action would be to work on an external repo, on something like github, bitbucket, or google code. 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: Speeding up test running
On Thu, Jan 14, 2010 at 7:59 PM, Vitaly Babiy wrote: > I have also been thinking about this, I think there is one problem but I am > not sure. This is when you have functional test and they need talk to a > database. In most cases you will be using transactions which should be fine, > but if for some reason you can't use transaction for test this will have to > run each one on its own. > Vitaly Babiy > > > On Thu, Jan 14, 2010 at 4:16 PM, ptone wrote: >> >> This is probably just a curiosity, but I was playing with ways to test >> the raw power of my new 8-core mac pro and was looking at how to apply >> this to testing. >> >> By using multiprocessing I was able to reduce the running of the >> current trunk tests from 6 minutes to 3. >> >> Because a test case needs to be pickled to be pushed to the worker >> pool and not all test cases could be, almost 2 minutes of this is >> spent having to run just several tests in the main thread. If this >> was resolved, I think the whole test suite could be run in about a >> minute. >> >> When it hits a stretch of tests that can be dispatched and lights up >> all cores, it just screams. >> >> With the increase of multicore machines, perhaps this is something of >> interest. Even with fast fail - waiting for tests to run takes away >> from other development tasks, and being able to run the test suite >> more frequently would probably help catch some bugs earlier before >> they cascade or propagate by being extended or referred to. I'll >> grant this is a relatively low priority - but if anyone wants, I'd be >> happy to clean up my hack and post it as a gist. >> >> -Preston >> >> -- >> 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. > > ISTM that if the only issue is knowing whether a test is isolated by a transaction that's an easy problem to solve, we already have a way of knowing that, the class of test itself! 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: AnonymousUser has_perm/has_module_perms function check authentication backends
On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel wrote:
>
> Am 18.01.2010 um 22:26 schrieb Luke Plant:
>
>> Hi Harro,
>>
>>> Hmm I guess I'll just have to keep on hacking django then..
>>> because that 1% case is something I keep running into for every
>>> project in one way or another.
>>> And if it was designed for most apps, why was the row level
>>> permission bits added? It's useless without simply always being
>>> able to call request.user.has_perm('permission', obj)
>>
>> Despite a slight overstatement in that last paragraph, your argument
>> seems pretty good to me. The whole point of these methods is to allow
>> custom backends to implement their own logic, so obviously it is
>> pointless to arbitrarily limit it.
>>
>> The only downside is that custom backends need to be able to cope with
>> anonymous users being passed to the has_perm methods, but that is
>> already well catered for with the is_anonymous() method. It is also
>> better to make this change before 1.2 lands, otherwise we have a
>> slight backwards incompatibility if we wanted to do it in the future
>> (backends could break if they unexpectedly got an AnonymousUser
>> instead of a User).
>>
>> Anyone got a good reason reason why this *shouldn't* go in? I'm +1 on
>> committing.
>
> Hm, I don't see a good argument to allow anonymous users to have a
> permissions, to be honest. Anonymous users are by definition not
> authenticated. Giving them more meaning by being able to grant them
> permissions doesn't make them anonymous anymore, right?
>
> Also, before adding those hooks to the ModelBackend, AnonymousUser never
> returned True when asked if it has a permission or not. Why should it now?
>
> Jannis
>
>
> --
> 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.
>
>
>
>
I think the best argument in favor of it is using permissions with
reusable applications. Say I have a wiki application I write, I don't
know whether anonymous users should be able to edit pages, I could
make it a setting, but that's ugly. Instead the natural thing to do
is ask the auth backend and let the developer implement it however.
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: AnonymousUser has_perm/has_module_perms function check authentication backends
2010/1/18 Noah Silas :
> I'm not certain I understand - if anyone can perform some action, what's the
> point of protecting it with a permissions check?
> ~Noah Silas
>
>
> 2010/1/18 Łukasz Rekucki
>>
>> 2010/1/18 Alex Gaynor :
>> > On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel
>> > wrote:
>> >>
>> >> Am 18.01.2010 um 22:26 schrieb Luke Plant:
>> >>
>> >>> Hi Harro,
>> >>>
>> >>>> Hmm I guess I'll just have to keep on hacking django then..
>> >>>> because that 1% case is something I keep running into for every
>> >>>> project in one way or another.
>> >>>> And if it was designed for most apps, why was the row level
>> >>>> permission bits added? It's useless without simply always being
>> >>>> able to call request.user.has_perm('permission', obj)
>> >>>
>> >>> Despite a slight overstatement in that last paragraph, your argument
>> >>> seems pretty good to me. The whole point of these methods is to allow
>> >>> custom backends to implement their own logic, so obviously it is
>> >>> pointless to arbitrarily limit it.
>> >>>
>> >>> The only downside is that custom backends need to be able to cope with
>> >>> anonymous users being passed to the has_perm methods, but that is
>> >>> already well catered for with the is_anonymous() method. It is also
>> >>> better to make this change before 1.2 lands, otherwise we have a
>> >>> slight backwards incompatibility if we wanted to do it in the future
>> >>> (backends could break if they unexpectedly got an AnonymousUser
>> >>> instead of a User).
>> >>>
>> >>> Anyone got a good reason reason why this *shouldn't* go in? I'm +1 on
>> >>> committing.
>> >>
>> >> Hm, I don't see a good argument to allow anonymous users to have a
>> >> permissions, to be honest. Anonymous users are by definition not
>> >> authenticated. Giving them more meaning by being able to grant them
>> >> permissions doesn't make them anonymous anymore, right?
>> >>
>> >> Also, before adding those hooks to the ModelBackend, AnonymousUser
>> >> never returned True when asked if it has a permission or not. Why should
>> >> it
>> >> now?
>> >>
>> >> Jannis
>> >>
>> >>
>> >> --
>> >> 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.
>> >>
>> >
>> > I think the best argument in favor of it is using permissions with
>> > reusable applications. Say I have a wiki application I write, I don't
>> > know whether anonymous users should be able to edit pages, I could
>> > make it a setting, but that's ugly. Instead the natural thing to do
>> > is ask the auth backend and let the developer implement it however.
>>
>> This argument convinced me to like this idea :) My only concern is
>> that, a newly created user could have fewer permissions then an
>> anonymous one. I can't think of a situation where this would be
>> useful. So maybe all other users could actually inherit those
>> "anonymous permissions" ?
>>
>> >
>> > 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://g
Re: TimeField for duration
On Wed, Jan 20, 2010 at 6:31 PM, Ian Kelly wrote: > 2010/1/20 Łukasz Rekucki : >> 2010/1/21 Jerome Leclanche : >>> Hi Lukasz, thanks for the wrap up >>> >>> Main issue is precision. I personally very, very often work with >>> milliseconds, and I can imagine many use cases where I'd need to work >>> with microseconds. How many of these backends do not at least support >>> millisecond precision? >> >> From my understanding of the docs PostgreSQL can do microseconds >> (6digits), Oracle - nanoseconds (9digits), SQLite3 seems to accept >> miliseconds in string representation "HH:MM:SS.SSS". >> >> And the worst case is MySQL: >> >> """A trailing .uu microseconds part of TIME values is allowed >> under the same conditions as for other temporal values, as described >> in Section 10.3.1, “The DATETIME, DATE, and TIMESTAMP Types”. This >> includes the property that any microseconds part is discarded from >> values stored into TIME columns.""" >> >> After seeing all this mess, i'm +1 on using BigIntField. Good work. > > In other words, all the same limitations that we already handle for > TimeFields. This looks to me like a green light to just use the > native datatypes. > > I see another big downside to the BigIntField approach: you can't add > TimeFields and IntervalFields at the database level (e.g. with F > expressions). I'm not sure how PostgreSQL or MySQL would handle this > if you tried it, but I know what Oracle would do: it would accept the > SQL as valid, it would interpret the IntervalField value as a decimal > number of /days/, and it would return a completely incorrect result. > > Cheers, > Ian > > -- > 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. > > > > Ian, FWIW there's a ticket with a patch (of unkown quality :P) for support for using timedeltas with F() expressions. 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: Pony request: refetch method to models
2010/1/27 Jukka Välimaa : > Sounds reasonable. I couldn't find an existing ticket, so I made a new one, > #12709. > --Jukka > > On Wed, Jan 27, 2010 at 2:34 AM, Russell Keith-Magee > wrote: >> >> On Wed, Jan 27, 2010 at 12:59 AM, Jukka wrote: >> > Hi all, >> > >> > I'd like to propose adding a method to Model that can be used to fetch >> > a "fresh" version of a model object from the database. >> >> This isn't a completely unreasonble idea, but it is an unreasonable >> time to suggest it :-) >> >> We are days away from our feature freeze for 1.2. At this point, any >> new ideas will need to wait until 1.3. >> >> I'm fairly certain this idea has been proposed before, so there's >> probably a ticket for it, too. If there isn't, open a new ticket so we >> don't forget the idea. >> >> If you want to propose this for 1.3, keep an eye on the release >> schedule; once 1.2 is released, we'll start discussing the features we >> want in 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. >> > > -- > 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. > I'm almost positive this is a dupe of another ticket, in the 3000-6000 range I think. 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: Pony request: refetch method to models
On Wed, Jan 27, 2010 at 12:23 PM, Karen Tracey wrote: > On Wed, Jan 27, 2010 at 12:17 PM, Alex Gaynor wrote: >> >> I'm almost positive this is a dupe of another ticket, in the 3000-6000 >> range I think. > > The one I found was #901. > > Karen > > -- > 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. > That one may be the one I'm thinking of (I've apparently seen it before anyways), but I seem to recall one with a patch on it. 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: Reg. Improving Django response time
On Thu, Jan 28, 2010 at 3:53 PM, saran_ATD wrote: > I have Django installed in SUSE Linux with postgres. It is working > great. Kudos > I have an issue. I have total database structure containing more than > 100million rows. I have partitions and indexes. It is taking plenty of > time to load Django initially. I meant in minutes. I can take a coffee > break and a short workout schedule. Is there any ideas/links and other > resources to speed up the response time (Throughput) > For you information, I am looking at Cache and DB tunning. Any other > tricks with Django, anything you are familiar with it? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > The django-developers mailing list is for the discussion about the development of django itself, not using django. Please use the django-users mailing list or the #django channel on Freenode IRC. 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: #3591 - Custom app_label in Django 1.2?
On Thu, Feb 4, 2010 at 11:06 AM, Adam Nelson wrote: > I don't suppose there's any way to get the patches from ticket #3591 > into Django 1.2? If not, can it be marked as definitively not in 1.2 > so I can roll a custom solution for myself? It's always hard to tell > from the ticket details what stage tickets like that are in. > > Thanks, > Adam > > -- > 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. > > The patches on this ticket will not land for 1.2. That ticket contains a series of very large patches, and I don't think a firm design decision has ever been made about the status of that ticket, and it was never on the 1.2 feature list. 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: Assertion Woes
On Fri, Feb 5, 2010 at 6:47 PM, FeatherDark wrote: > So I installed pyWin32 today and all of my Django sites went POOF into > non-happyland > > I was prompted to post so here's a dpaste of just 1 of the errors in > the apache log > > I removed pyWin32 and all my Django woes vanished... other than I > needed pyWin32 > > http://dpaste.com/155209/ > > assert sys.modules[modname] is old_mod > > -- > 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. > > I can say, with very good confidence, that whatever the bug here is, it's not with our code. Our dynamic importing code (importlib) was written by Brett Cannon, one of the experts of the python import system, and author of importlib (which he personally backported from python 2.7/3.2 into Django). I'm therefore, seriously inclined to think the bug is in pyWin32. 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: Refining Django admin look proposal
On Sat, Feb 6, 2010 at 1:02 AM, Russell Keith-Magee wrote: > On Fri, Feb 5, 2010 at 5:37 PM, j...@jeffcroft.com wrote: >> All due respect to Wilson (he's a great designer, a good friend, and >> he and I have talked on several occasions about the Django admin >> interface), I have to agree that the Django admin interface is dated >> and has some UI issues that could use work. I can also confirm that >> Wilson himself says this, and won't be offended by anyone else saying >> so. Wilson is one of the very best designers I've ever had the >> pleasure of working with, but he's not immune to the same "God that >> thing I made five years ago kind of sucks by today's standards" >> feeling we all have. >> >> As a designer who has been closely associated with the Django project >> for over four years, I gotta say: the feeling that no one but Wilson >> can contribute to an admin interface redux is a major frustration. >> I've talked about it with other great designers who love Django, >> including Nathan Borror and Bryan Veloso, and I think I can speak for >> all of us when I say we feel as though it's really not worth our time >> to propose an update for the admin interface, because if it doesn't >> come from Wilson, it won't be taken seriously by the core team. > > I'm sorry if I gave that impression. My comments were intended that > while the admin can certainly be improved, but it isn't "fundamentally > flawed" as the OP seemed to imply, and we will hold a very high > standard to anyone proposing design changes. It was also intended to > point out that "OMFG, the design elements aren't all left aligned" > isn't necessarily an indication of bad design. > >> Every time an update to the admin interface comes up, I hear one of >> two arguments against it from core devs, and both of them are, quite >> frankly, inaccurate: >> >> 1. "Wilson is the admin interface's designer, and he'll update it when >> he deems it necessary." -- No, he won't. He's a busy, busy man working >> on paying projects and from my discussions with him, I don't believe >> he has time for this (although I do believe he would *like* to do it). > > I completely agree. Unless Wilson is specifically offering a new > design -- and not in an abstract, "oh yeah, I'll do that" kind of way > -- we should make way for someone else. > Agree completely. >> 2. "The interface was designed by Wilson F'ing Miner of Apple.com fame >> and therefore it can not possibly have any UI issues." -- Wilson >> himself will be the first person to tell you this isn't true. There >> are UI issues. The look is dated. A lot of the template and javascript >> code sucks. It was a great piece of interaction design in 2005, but >> that was five years ago. Nothing on the web from five years ago is >> still awesome by today's standards. Nothing. > > Again, completely agreed. > Ditto (although I still believe the admin has aged exceptionally well). >> The Django admin needs an update, and I think it's high time the core >> devs start making other talented designers feel as though if they put >> the effort in, their contributions will be seriously considered for >> inclusion in Django. > I honestly don't know where this impression comes from. Either I've missed a long string of messages on this mailing list, or there's something else going on? There have been many improvements to the admin-ui over the past releases including, but no limited to: * admin actions * list editable * the GSOC admin-ui work * readonly fields While none of these are the comprehensive reform that is being discussed here, it's should be clear that improvements are always welcome, but for something large, like a compete refactor, it's going to be the kind of thing where someone needs to do almost all of the work themselves. None of Django's core developers are designers, nor can they necessarily execute someone else's creative vision. > Ok - let me put my cards on the table: > > * I'm a member of the core, and I would *love* to see a comprehensive > design refresh of the admin. > > * Wilson is *not* the only person that can do the job. Wilson is > certainly welcome to propose a design change, but I think this is a > perfect opportunity for Django to shine the spotlight on the design > talent of others in our community. > > * However, the work needs to be done by someone that knows what they > are doing. Wilson's work isn't perfect or irreplaceable by a long > shot, but it does set a high bar. We're not going to change designs > just so we can wash the Wilson out of it. > > * This isn't an exercise we're going to repeat every 3 months just > because we can. If we do a design refresh now, I would expect that we > won't do another one for another couple of years. > > So, to I'd like to make a proposal. Lets have a competition for a > redesign of the admin + databrowse. We accept proposals to anyone that > wants to make them, and the winner gets their code as the new admin > interface in trunk. >
